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The multi-backended database system (MBDS) is a database system designed 
for very large databases. MBDS is intended to provide consistent performance 
with increased capacity (or improved performance at a sustained capacity) by dis- 
tributing the work of the system among several micro-computers connected to a 
common communication network. One of the issues central to the MBDS design 
is the portability of the system’s software. This thesis provides a general discus- 
sion of the issues involved in software portability, and then presents a case study 
of the MBDS software system. 
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I. AX INTRODUCTION 



A. THE BACKGROUND 

It should come as no surprise to anyone involved in computer science to say 
that the essence of the entire field is changing. This is probably true for those 
persons involved in software development. The trend of rapidly decreasing 
hardware costs remains steady, and shows no signs of changing course in the near 
future. Software costs therefore represent an ever increasing percentage of total 
system costs. 

As the level of technology increases, and the relative costs of hardware con- 
tinues to decrease, the expense of upgrading to larger, more powerful computing 
systems becomes less restrictive. Except for the ever present (and increasing) cost 
of new software, the obvious requirement then is for the software to be easily 
ported from one system to another. Assuming an environment of truly portable 
software, users would find themselves in a situation where the only real costs to be 
considered when evaluating a change to a new system would be the cost of the 
hardware alone. 

There are some obvious benefits to this situation. When the need arises for a 
greater capacity or an increased throughput to meet the new requirements, the 
upgrade becomes an easier task. Additionally, more powerful software can be 
purchased at the outset, when the original computing systems are acquired. Since 
the useful life of a software item would no longer end when its underlying 
hardware is replaced, higher initial expenses for software could be justified. 
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Cost is not the only factor in support of software portability. It is often desir- 
able to provide a uniform, consistent environment across several different comput- 
ing systems. The days of the single mainframe which supports all of the com- 
puter needs in an organization are fading. Many organizations now have several 
different computing systems (usually minis or micros). They may be made by 
different manufacturers, run by different operating systems, used for different 
tasks, and are networked together frequently to provide a very powerful comput- 
ing environment where resources may be shared. 

It is also common to see that the same operating system is running on several 
different computers (e.g., UNIX, which runs on VAX main frames, ISI 32-bit 
micro-computers, IBM 16-bit micro-computers, et. al.). Conversely, hardware 
manufacturers often provide a choice of operating systems which will run on the 
same hardware: and applications developers will provide versions of their software 
which run under different operating systems, and allow exchange of data between 
them without modification. In such an environment it is not unreasonable for a 
user to desire programs which can be moved between several computing systems. 

B. AN OVERVIEW 

Portability is essentially the ability of software to migrate among different 
hardware configurations and operating systems with little, or no. modification. 
This thesis will provide a discussion of techniques which can be used to achieve a 
higher degree of portability for software in general, and database management 
software in particular. 

The need for portable software is evident through all areas of computer sci- 
ence. database management systems (DBMS) present a particularly strong need 
for it. Conceptually. DBMS software can be thought of as a specialized operating 
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system. Like an operating system. DBMS accepts commands from a command 
language (data language), and uses the commands to manage and manipulate files 
(data). System users utilize both DBMS and the operating system as support 
tools. Like operating systems, the DBMS software tends to be complex and 
expensive, often taking many years to develop. 

The DBMS software however presents something of a paradox in that the 
more powerful DBMS is, the quicker it exceeds its usefulness. This happens not 
because DBMS ceases to be adequate, but because the hardware on which the sys- 
tem is running can no longer handle all of the work which the DBMS software is 
trying to accomplish. 

The better DBMS is, the more users there are. Unfortunately, the increasing 
strain which a growing database places on a computing system is not linear. 
Response times increase drastically, and soon, running nondatabase operations 
concurrently with DBMS becomes infeasible. Eventually, even running DBMS as 
a standalone system becomes uneconomical. 

One obvious answer to this dilemma is to go to larger, stand alone, comput- 
ing systems for handling database functions. There is no reason to believe, how- 
ever. that this is anything but a short-term solution. Databases will almost always 
continue to grow, so the emphasis is once again on the need for the portable 
DBMS software which can be moved from one system to another system. 

Researchers in the area of database management are finding new ways to 
improve the efficiency of the DBMS software, and reduce the strain that the 
DBMS software imposes upon the mainframes called hosts. One current project, 
is the multi-backended database system (MBDS). MBDS is aiming at meeting 
both of these goals by placing the DBMS software on independent micro- 
computers known as the backends which are connected to each other, and to their 
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host via a communications link. Since most processing with MBDS is on indepen- 
dent computers, no real strain is placed upon the host computer. MBDS provides 
for increased capacity without decreased performance (or increased performance 
at the same capacity), by the addition of micro-computers. 

MBDS places no restraint on either the host computer type, or the micro- 
computer backend. There is also no restriction on the method used to establish 
the communications link. In order to provide this freedom, and since the system 
is designed with the intention of migrating to various hardware configurations 
(possibly at frequent intervals), the MBDS software must be easily portable. 

Due to the great desire for portability in database software and the addi- 
tional efforts by the designers of MBDS to achieve it, MBDS represents an excel- 
lent example of methods which can be used to provide software portability. The 
methods used are applicable to the software portability in general, and to the por- 
tability of the DBMS software in particular. As such, one implementation of the 
MBDS design is used for discussion throughout this thesis. A complete descrip- 
tion of MBDS design can be found in Reference 1 and Reference 2. 

C. THE ORGANIZATION OF THESIS 

Chapter II presents a paradigm for a softw'are system, and describes the parts 
of a computing environment. A discussion is presented on how the various com- 
ponents of a software system (presented in the paradigm) interact with each part 
of the computing environment. Also discussed are the effects that changing each 
part of the computing environment have on the components of a software system. 

In chapter III we describe the components of the multi-backended database 
system (MBDS) according to the framework of our paradigm. The porting of 
MBDS from one computing system to another is discussed, and the effects of the 
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porting on the MBDS software components are presented. The actual 
modifications which are necessary to port the MBDS software are presented in 
chapter IV. 
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II. THE SOFTWARE-SYSTEM PORTABILITY 



Before progressing with any discussion of how to achieve the portability of a 
software system we must have some concept of what portability is, and what 
comprises a software system. Only then can we correctly determine what the 
issues are and their impact upon the portability, and how these issues should be 
approached and analyzed. Probably no two definitions of the software portability 
exactly coincide, depending on the background of the person providing the 
definition, and the scope of the problem at hand. However, there are some gen- 
eral points that all of the different definitions are likely to agree on. 

The software-system portability is the ability of a software system to migrate 
from one to another computing environment (i.e., hardware and operating system 
combinations) with little, or no, changes of the software system required. Changes 
which are required should be consistent and of a regular nature, so that these 
changes can be accommodated, if possible, by some mechanical means. 

Given this definition, we now must focus on what constitutes a software sys- 
tem. Software systems can be designed for many different purposes. In order to 
carry out their intended job they usually have various parts (some times hundreds 
of them), each of which satisfies some specific requirement. There are usually sec- 
tions for carrying out normal processing and for creating and manipulating data 
structures. Most software systems also require access to device drivers to enable 
terminal I/O or communication with other softw’are systems, either within the 
same computer or over some distributed network. 
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Regardless of the software system in question, its portability is not deter- 
mined by what the software system is intended to do. or how many parts it has. 
but by how the software system was structured. Therefore, the issues affecting 
the portability are general to all types of software systems, since all of the 
software systems have some structure. The concepts to be discussed do not vary, 
nor does its basis, on whether the software system is a database system, operating 
system, a compiler, or any other type of systems. In the rest of this chapter we 
examine what those issues are. A case study on the portability is presented in the 
next chapter, using the multi-backended database system (MBDS) as an example. 

A. A PARADIGM FOR A SOFTWARE SYSTEM 

In this section we present a paradigm for the structure and form of a software 
system. This paradigm is based on the two types of components that are used to 
construct a software system. They are system source code and operating system 
commands. There are three types of system source code, namely, 

• machine code. 

• assembler code, and 

• high-level code. 

Operating system commands take the form of 

• basic commands, 

• command files, and 

• utilities. 

First, we investigate the system-source-code component. For each type of 
code in the system-source-code component, our paradigm provides up to three 
types of processing: 
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• basic processing. 

• runtime-environment processing, and 

• translator-environment processing. 

In the following discussion, we investigate the form that each of the three kinds of 
processing takes for each of the three types of the system source code. 

The machine code is just binary code written for the particular machine the 
program runs on. The basic processing functions for machine code include opera- 
tions such as add, subtract and store. There is no runtime-environment process- 
ing, or translator-environment processing available with the machine code. 

The assembler code, while it is at a higher level than the machine code, usu- 
ally results in only a few machine instructions per line of the source code. The 
capabilities at the basic processing level for the assembler code parallel those of 
the machine code. However, the assembler code allows logical names and per- 
forms the automatic calculation of machine addresses. The runtime-environment 
processing for the assembler code involves calls to the operating system for per- 
forming such functions as reading characters from files, or obtaining the current 
date and time. Assemblers generally do not provide any translator-environment 
processing capabilities. 

The high-level code refers to compiler languages such as C or Pascal. For the 
high-level code, basic processing capabilities include mathematical operations, log- 
ical comparisons, and assignment of values to logical variables. They also include 
all those statements in the language which we call the runtime-environment pro- 
cessing or translator-environment processing. The runtime-environment- 
processing capabilities include operations such as reading and writing files, 
dynamically allocating the memory and providing calls for communicating with 
other software systems. The high-level calls to be carried out by the operating 
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system constitute the runtime-environment processing. The translator- 
environment processing is any function that is carried out by librar\’ routines 
which are provided as a part of the translator and incorporated into the software 
system at the link time. Included in the translator-environment processing are 
operations such as floating-point arithmetic, computation of trigonometric values 
and manipulation of character strings. 

Now let us consider the operating-system-command component of a software 
system. The basic operating system commands include those for compiling, 
assembling and linking the source code of all types (i.e., machine, assembler and 
high-level); and for deleting, copying and renaming flies. Command files are lists 
of basic processing commands which automatically execute, in sequence, or 
according to some programming logic dictated by the operating system. The util- 
ities of the operating system are prewritten command files which are included as a 
part of the operating system. Utilities may perform logically complex operations 
and are designed to aid in the implementation and management of large software 
systems. Included in these are system libraries and implementation aids such as 
version control systems and file-creation utilities. 

We should take the time here to note an important point. While all of the 
code is eventually translated into the machine code and runtime libraries may 
make calls to the operating system, neither of these directly affects the portability 
of the software. The issues are what types of the system source code that the 
software system is written in, and which types of processing are performed. These 
are what determine the portability of the software system. 
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B. TYPES OF PORTING 

We have defined the porting as the movement of a software system form one 
computing environment to another. There are three parts which make up a com- 
puting environment, 

• the hardware. 

• the operating system, and 

• the translator (in the case of the assembled or high-level code). 

A software system may be ported by changing any of the three parts of the com- 
puting environment. Each of these changes has a different impact on the software 
system being ported. There may of course be changes to several items at once. 
For example, a change of operating systems usually requires a change of transla- 
tors as well, since most compilers are written to run on a particular operating sys- 
tem. We now use the paradigm we have created to examine the effects that each 
type of porting has on a software system. 

1. A Change of the Hardware 

For any software system, the most profound effects of changing hardware 
are in the system-source-code component. Any portions of a program written in 
the machine code obviously are affected by a change of the hardware. Unless the 
new hardware used allows for the emulation of the original machine, all machine 
code must be rewritten. The assembler code usually must be redone as well 
because it is so closely tied to the structure of the underlying machine. 

The high-level code usually does not have to be redone due solely to a 
change of hardware as long as that new hardware supports a compatible version 
of the original operating system and that a compiler is available for the high-level 
language in question. However, this is not always the case. If the high-level 
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language is not widely used (e.g.. BLISS), then there might not be a compiler 
available with a code generator for the new machine. 



Operating-system commands are not affected by a change of the 
hardware alone, since two versions of an operating system running on two 
different sets of hardware can usually be expected to provide the same functions. 
Thus, in the case of a hardware-only change, the type of code used (machine, 
assembler, or high-level) is what determines the changes to be made to the system 
source code. There is usually no affect on the operating-system-command com- 
ponent of the software system. 

2. A Change of Translators 

Changing the translator only has an effect on the assembled and high- 
level code in the system-source-code component (the machine code does not use a 
translator). The kinds of processing which the code (assembled or high-level) per- 
forms affect the changes which have to be made. Necessary changes to the code 
which accomplishes the basic processing are determined by the degree of the 
language’s standardization. 

In addition to intentional design differences there is a question of 
whether a particular translator correctly implements the intended language. For- 
mally validating compilers for modern high-level languages is not possible. Most 
commercial compilers are subjected only to some series of empirical tests. If 
minor differences from the defined language are detected, manufacturers may 
decide to document the deviations, rather than pay the expense of trying to 
correct them. These deviations may affect how well a software system reacts to a 
new compiler. 

Even if the syntax of a language is standardized, changes may be 
required in portions of the code which do the translator-environment processing. 
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The runtime libraries provided by the compiler suppliers are not always the same. 
A good example of this is Pascal's string manipulation routines. While the 
language itself does not define string types, almost all implementors include them 
as an extension to the language. However, the format used by each is not stand- 
ardized and often differs among compilers. While the old and new translators may 
both provide functions that have the same name and take the same parameters, 
there may be logical differences in how each of them implements these functions. 
If these functions perform critical operations in the software system, it may be 
desirable to avoid the runtime-environment processing whenever possible and 
write your own routines instead. 

For the system-source-code component of a software system, the changes 
necessitated by a change of translators is determined by the type of processing 
done by the code. There is usually no effect on the operating-system-command 
component of the software system. 

3. A Change of Operating Systems 

It is the operating system which provides the major functionality in a 
computing environment. A change of the operating system therefore is the most 
drast'ic kind of porting. Porting software to a new operating system may affect 
the assembler-code and high-level-code portions of the system-source-code com- 
ponent. The machine code (which relies only on the underlying machine) does 
not have to change. The most direct effects of changing operating systems are to 
those code sections which do the runtime-environment processing. If the new 
operating system does not provide equivalent functions for those operations, it 
may become necessary to redesign the logic of entire sections of the code. 

The portability of a software system may also be complicated by the fact 
that a change of operating systems requires some changes to the translator which 
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the software system has used. This subjects the software system to all of the pos- 
sible changes it would have to undergo for any other change of translators. 
Therefore, changing operating systems has an indirect effect on the code which 
does the translator-environment processing and, possibly, the basic processing as 
well. 

Changing operating systems obviously affects all parts of the operating- 
system-command component of a software system. Basic commands (e.g., com- 
pile, link, search, etc.) are almost always supported in some form by the new 
operating system: command files usually are available as well. Therefore, the 
changes required by these commands are a matter of substituting the new formats 
for the old. The greatest difficulties arise if operating-system utilities have been 
utilized and the equivalent utilities do not exist in all operating systems. When 
they do exist, their formats may not be at all similar. In either case, an extensive 
restructuring may be necessary to maintain the software. 

The porting to a new operating system may require major changes to 
both components of a software system. In the system-source-code component, the 
assembler and high-level code may have to be changed. These changes may affect 
the code which does any of the three types of processing. For the operating- 
system-command component, a major rewriting is usually necessary for all three 
forms of operating-system commands. 
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III. THE IMPACT OF THE MBDS DESIGN ON PORTABILITY 



In this chapter we present a case study of the porting of a particular software 
system from one computing environment to another computing environment. 
Our description of the software system that was ported follows the structure of 
the paradigm presented in the previous chapter. The description of the actual 
porting also follows the format we presented in the previous chapter (i.e., describ- 
ing each part of the computing environment which changed and how the change 
affected each component of the software system that was ported). 

The software system that was ported for our case study is the multi- 
backended database system (MBDS). MBDS is a database system (for very large 
databases) that was developed for research purposes at the U. S. Naval Postgra- 
duate School. The basic premise of MBDS is to distribute the work of the data- 
base system across several different micro-computers. MBDS uses one computer 
as the system controller, and several other computers (at present, eight) as back- 
ends to accomplish the majority of the required database-manipulations. There 
are two reasons why MBDS was chosen for our case study; 1) MBDS has been 
ported successfully twice since its initial implementation, and 2) the MBDS 
designers have established portability as a high priority since the initial inception 
of the MBDS project. Including the first implementation. MBDS has been run in 
three different computing-environments. Among the three computing- 
environments, there have been four different hardware configurations (MBDS uses 
more than one computer per environment), and five different operating systems. 



20 



To attain a portable software system, the designers of MBDS strived to 
develop the MBDS softw'are so that it contained a high degree of hardware and 
operating-system independence. By engineering MBDS with a minimum amount 
of dependencies, they greatly enhance the probability that the software system 
would be easily transportable to new, and varying, hardware/operating-system 
configurations. 

To develop a highly portable database system, the designers of MBDS first 
identified which portions of the database system software are dependent on either 
the hardware and/or the operating system. They identified two classes of data- 
base system software which are dependent, namely, communications software and 
disk input/output software. Communications software is used by the database 
system to communicate among different computers and to communicate within a 
computer, referred to as inter- computer and intr a- computer communications. 
respectively. The communications software is often affected by a change of the 
operating system (since communications protocols are operating-system depen- 
dent) and is also affected by a change of the hardware (since specialized commun- 
ications drivers are hardware dependent). The disk input/output software is used 
by the database system to access and process information from the secondary^ 
storage. The disk input /output software is also affected by a change of the 
operating system (since it is operating-system dependent) or by a change of the 
hardw'are (since it is dependent on specialized disk drivers). 

In general, there is no way to avoid a certain amount of hardware and 
operating-system dependencies in a database system. Instead, MBDS was 
developed with techniques which can minimize the effect of changes. There are 
two distinct approaches to accomplishing this task. First, MBDS uses the con- 
cepts of abstraction and encapsulation to isolate the dependencies of the 
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communications and disk input/output software. The database system software 
makes calls to these high-level routines that are dependent on the programming 
language used in the software system, when there is a need to access the system- 
dependent software. These calls are generic, e.g., send[message. destination], 
receive [mess age, sender], do disk iojdata, device]. They represent abstractions of 
the actual functions. The routines themselves (i.e., send, receive, and do disk io) 
are used to encapsulate the system-dependent software. Second, the designers 
used the concept of a virtual interface to develop independent software for com- 
munications and disk input/output. The aim of the virtual interface is to utilize 
abstractions provided by the compiler to accomplish a particular task. These 
abstractions are usually in the form of library routines for the programming 
language. As these librarj" routines are supported by different compilers under 
different operating systems, it is easy to transport the virtual interface from one 
operating system to another. 

MBDS has utilized the abstraction and encapsulation concepts, as well as the 
creation of a virtual interface. Abstractions and encapsulations are used by the 
MBDS communications software to provide high-level calls to send and receive 
messages both among and within computers. Since MBDS is a message-oriented 
system, all of the inter-computer and the intra-computer communications are 
accommodated by the abstractions and encapsulations. These techniques are also 
used by the MBDS disk input/output software to provide a high-level interface 
for reading (writing) information from (to) the secondary storage. In addition, 
the MBDS designers also created a virtual interface for disk input/output 
software. The virtual interface depends on the programming language constructs, 
and is used to provide a high-level, operating-system-in<Jependent paradigm for 
performing disk input /out put via text files. 
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In the next section we take a closer look at the construction of MBDS accord- 
ing to our paradigm of a software system. An in-depth description of the MBDS 
design can be found in Reference 1 and Reference 2, descriptions of the implemen- 
tation of MBDS can be found in Reference 3 and Reference 4. 

A. THE xMBDS COMPONENTS 

The system-software component of MBDS contains only high-level code 
(there are no sections of machine code or assembler code). This has greatly 
enhanced the portability of the MBDS software system. The MBDS high-level 
code (written in the C programming language) performs all three types of process- 
ing contained in our paradigm (i.e., basic, runtime-environment and translator- 
environment processing). 

The basic-processing operations of MBDS are the normal C language con- 
structs which would be found in any C program (e.g.. for-loops. while-loops, if- 
then-else statments, etc.). These basic-processing operations carry out the major- 
ity of the processing in the MBDS software. We have stated in the previous 
chapter that portions of the system-source-code component which are written in 
high-level code and perform basic-processing operations are inherently portable. 
Therefore, the majority of the MBDS software system is inherently portable. The 
portions of MBDS which do runtime-environment-processing are those sections of 
high-level code which perform inter-computer communications, intra-computer 
communications, disk input /output and system-timer operations. 

Translator-environment-processing operations in MBDS are performed by 
function libraries provided with the C compiler. They consist essentially of rou- 
tines for performing terminal input /output and routines for the extensive 
character-string manipulations which the MBDS software performs. MBDS also 
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performs some disk input/outpui at this level, when dealing with files used for 
execution-trace information and user input. All of the manipulation of the 
database-files is done at the runtime-environment processing level, under the guise 
of abstraction, encapsulation and virtual interface techniques. 

The system-software component of MBDS consists of over eighteen-thousand 
lines of C code. In order to implement and manage such a large software system 
the designers of MBDS make extensive use of the operating-system-command 
component of MBDS. Operating system command-files are used to gather the 
required system-source-code files in one place, compile and link them into execut- 
able files, relocate all executable files in one area for later execution, and then 
erase any intermediate (temporary) files which are no longer needed. In addition, 
since the MBDS software system consists of multiple processes running across 
several computers (usually five processes per computer), command files are util- 
ized to initially start the system in an orderly fashion. 

B. PORTING THE MULTI-BACKENDED DATABASE SYSTEM 

This section discusses the actual changes made to the MBDS computing- 
environment each time MBDS was ported, and the effects that each of those 
changes had on the MBDS software. Each time MBDS was ported, changes were 
made to both the hardware and the operating system at the same time (the com- 
piler also changed, because of the new operating system). For the sake of clarity, 
each of these changes is discussed independently. 

1. Changing the MBDS Hardware 

MBDS has had three different hardware configurations, the first 
configuration is the original. The controller for MBDS is a Digital Equipment 
Corporation (DEC) VAX-ll/780. The backends are two DEC PDP-ll/44s. For 
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the database store, each backend utilizes a 67-megabyte RM03 disk drive. Inter- 
computer communications is accomplished using the point-to-point parallel com- 
munications link (PCL). a 0.5-megabit bus. Three PCL's are utilized, one from 
the controller to the first backend, one from the controller to the second backend 
and one between the two backends. 

In the second configuration the controller for MBDS is a DEC VAX- 
11/750, the backends for MBDS are eight Integrated Solutions Incorporated (ISI) 
Motorola 68020-based workstations. For the database store, each backend utilizes 
a 500-megabyte Control Data Corporation (CDC) winchester-type disk drive. 
Communications is accomplished using an Ethernet. All computers (both con- 
troller and backends) share the same Ethernet. 

For the third configuration, the controller for MBDS once again is a 
DEC VAX-ll/780, while the backends are upgraded to DEC MicroVax-IIs The 
communications bus is also upgraded to a DELNI. with DECNET providing the 
networking software interface. Each backend has a 71-megabyte DEC 
winchester-type disk drive. 

Since all of the MBDS software system consists of either high-level 
system-source-code or operating-system-commands, we can expect that no 
changes would be required to the software solely because of a change of the under- 
lying hardware. That is in fact what happened. In both cases, where MBDS was 
moved from one piece of computing hardware to another, no changes had to be 
made to the MBDS system-source-code (as a result of the hardware). There were 
also no changes required the operating-system-command component of MBDS. 

2. Changing the MBDS Source-Code Compiler 

A change of compilers was experienced by the MBDS high-level code (by 
circumstance) each time a change of operating systems was made. In the original 
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MBDS configuration the DECUS C compiler was used for high-level code which 
was developed on the PDP-11/44 computer (using the RSX-ll/M operating sys- 
tem). For code that was developed on the VAX-11/780 computer (using the 
VMS 3.7 operating system) the EUNICE C compiler was used (EUNICE emulates 
a UNIX environment on the VMS operating system). For the second MBDS 
configuration, the UNIX C compiler was used for high-level code on both the 
VAX-11/750 (using the UNIX 4.2 BSD operating system) and the ISI worksta- 
tions (also using UNIX 4.2 BSD). In the third version of MBDS the DEC C com- 
piler on Micro- Vax IIs was used (using the MVMS 4.1 operating system). This 
same C compiler was used to develop high-level code for the VAX-11/780. Since 
executable-code generated for the Micro-Vax II computer is upward compatible 
with the VAX-11/780, it was possible to develop high-level code for the Vax- 
11/780 on the MicroVaxs and then copy across the executable files. This avoided 
any risks of using yet another C compiler, and avoided using the VAX-11/780 for 
development purposes (since the VAX-11/780 was used for other purposes in 
addition to the MBDS research). 

Changes to system-source-code (as result of changing compilers) would 
normally be expected in sections of code which perform translator-environment 
processing. However this was not the case with the MBDS software, there were no 
changes required for code which performed translator-environment-processing. 
This is probably because the origin of the C programming language is closely tied 
to the UNIX operating system. Therefore, most developers of C compilers (for 
any operating system) provide compiler libraries which are copies of the original 
UNIX C compiler librarj'. 

There were some changes required in the MBDS high-level code which 
performed basic-process operations (as a result of the new compiler). These 
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changes were required when the MBDS software was ported from the second to 
the third versions (i.e.. from the UNIX C compiler to the DEC C compiler). 
Though the actual changes required were simple (and were needed in less than 
twenty lines of C code), the time required to determine the cause of the problem 
was considerable. Both compilers accepted the source code (they just interpreted 
it differently), so there were no error massages produced at compile time. Indica- 
tions of the compilers’ differences did not appear until the new executable files 
were run and the new version did not work! Keep in mind that a new compiler 
was not the only change which had taken place. This, along with the fact that no 
problems had arisen from previous compiler changes, and that the problems were 
in sections of code which performed basic-processing (the least probable area), 
served to create a difficult debugging problem. 

The difficulties apparently resulted from differences in the way the two 
compilers assigned precedences when multiple C language operators appeared in 
one line of code ( the C programming language allows certain short hand coding 
constructs to save typing time). The only changes needed were to remove these 
short-hand lines of code, and rewrite them in a manner similar to the way they 
would be written in any other high-level language (e.g.. Pascal). From a software 
engineering point of view, the short-hand coding techniques should have been 
avoided anyway, since they tend to be very cryptic, making the resulting source 
code difficult to read and maintain. 

3. Changing the MBDS Operating System 

Portions of the MBDS software have run on five different operating sys- 
tems. In the original MBDS configurations the controller used the DEC VMS 3.7 
operating system, while the backends used the RSX-ll/M operating system. For 
the second version of MBDS, both the controller and the backends used the UNIX 
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4.2 BSD operating system. In the third version of MBDS. the VMS 4.2 operating 
system was used for the controller, with MV\IS 4.1 running on each of the 
backends. 

As was stated in the previous chapter, a change of operating systems is 
the most drastic kind of porting for any software system. The MBDS software 
changes required as a result of a new operating system accounted for the vast 
majority of work needed, both in terms of time spent and percent of the MBDS 
software which had to be modified. While all of the MBDS system-source-code 
which performed runtime-environment-processing had to be modified, the changes 
were isolated to just a few source files. This was a result of the abstraction and 
encapsulation techniques used by the MBDS designers. Therefore, it was easy to 
predict the majority of the changes which must be made to accomplish the 
porting. 

Some minor changes must be made to sections of the MBDS code which 
performed system-timing operations. These changes consisted mostly of changing 
the names of functions which were called (from operating system libraries), and 
rearranging the order of some parameters to those functions. The majority of the 
system-source-code changes must be made in the sections of code which perform 
communications. 

For the original version of MBDS three different methods of communica- 
tion were used depending on whether the need was for inter-computer communi- 
cation. intra-computer communication in the controller, or intra-computer com- 
munication in a backend. Inter-computer communication was accomplished using 
a point-to-point parallel communications link. In the backends, intra-computer 
communication (under the RSX-ll/M operating system) was accomplished with 
shared memory techniques. For the controller, intra-computer communications 
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(under the \ MS 3.7 operating system) were performed using VMS mailboxes. 

hen the MBDS software was ported to the UNIX operating system none of 
these communication techniques existed. 

Under the UNIX operating system, all communication (inter-, and 
intra-computer) was accomplished using UNIX sockets. This meant that all code 
which performed the communications had to be changed. Due to the virtual- 
interfaces which MBDS had set up. these sections of code were again isolated to 
just a few source files. There was also the advantage that the virtual-interfaces 
could accomplish all three types of communications with just one low-level driver 
(UNIX sockets). However, when the third MBDS version was implemented it did 
not use UNIX, so all the communications drivers again had to be changed. 

The third version of MBDS used VMS mailboxes (like version one's con- 
troller) for intra-computer communication in both the controller and the back- 
ends. This meant that the source code which had been used in version one’s con- 
troller could be used (virtually unchanged) for version three's controller. In addi- 
tion. it could be used for the backends as well (with only minor changes). Inter- 
computer communications in the third version of MBDS were accomplished using 
DECNET. Since this technique had not been used in any previous MBDS ver- 
sions. entirely new communications drivers must be written. The virtual-interface 
techniques again isolated the changes to just a few files. 

The operating-system-command component of MBDS was rewritten each 
time MBDS was ported to a new operating system. There are in excess of twenty- 
five command-files used to manage the implementation of the MBDS software. 
So. while the required changes were mechanical in nature, they required a great 
deal of time to accomplish simply because of the number of files which were 
changed. Even though the controller for version one of MBDS ran on the VMS 
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operating system (like the controller and backends of version three), the controller 
software only represents about twenty-five percent of the MBDS software. There- 
fore. while some of the’ command files from version one could be used in version 
three (with minor modifications), there were still a great many command files 
which were rewritten. 
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IV.. A CLOSER LOOK AT THE MBDS PORT 



In this chapter we discuss the steps necessary to transform MBDS version 
two into MBDS version three. We examine the porting process in a chronological 
order, essentially presenting a journal of the activities used to move the software. 
A separate detailed discussion is presented of the changes made to the MBDS 
communications software (which underwent the greatest changes). First, lets look 
at the sequence of events used to accomplish the porting. 



A. THE SEQUENCE OF EVENTS 

Porting the MBDS software from one system to another has entailed several 
distinct phases. The major milestones in the sequence are as follows; 

• transfer the MBDS files (of source-code and operating-system commands) 
from the old computing system to the new one, 

• modify the operating-system-command files used for compiling the MBDS 
software, 

• compile the source-code files and correct any compile-time bugs which 
appear. 

• modify the MBDS intra-computer communications software, and implement 
an intermediate version of MBDS with a controller and one backend, both 
running on the same computer, 

• perform run-time testing on the intermediate system to ensure the actions of 
the implementation are logically correct (according to the MBDS design), 

• modify the MBDS inter-computer communications software to implement 
the final version (MBDS version three). 

• confirm the actions of the final version are logically correct. 

While some of these phases overlap to some extent, the porting sequence is clearer 
if they are considered separately. 
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The files of source-code and operating-sysTern-commands which comprise 
MBDS (version two) exist on one of the ISI workstations. The first step in the 
porting process is to copy all of the files to one of the Micro-Vaxs, where the 
development of MBDS version three has been accomplished. Since the computing 
systems for both versions of MBDS are connected to a common local-network, the 
files are copied using the standard communications utilities available. 

Once the are were on the new system, the next step is to convert the 
operating-system-command files. Since the command files are needed to manage 
the compilation of the MBDS source-code, their conversion must take place before 
the compilation of the system begins. Each implementation of MBDS contains 
six independently executed programs (or processes) for the controller and five 
independent programs (or processes) for each backend. There is a set of com- 
mand files for each of the independent programs. One command file in the con- 
troller source-code (and one in each backend) may call all of the subordinate com- 
mand files, and in this way the entire set of MBDS processes can be created from 
the top level. The total number of command files for the controller and backends 
(in version two) is approximately twenty- five. 

The command files in MBDS version two are UNIX makefiles. These have a 
capability for tracking which source-code files have been modified (and which 
have not) since the last time a program’s source-code files are compiled and 
linked. Makefiles also allow the programmer to state which source-code files are 
dependent on other source-code files. Through makefiles, only modified source- 
code files are recompiled, and they (and files dependent on them) are relinked. 
Some of the MBDS processes require over thirty-five source-code files, and each 
shares some common source-code files with the other MBDS processes. Therefore. 
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the management of the MBDS software Ls easier, and modifications can be accom- 
plished faster, when makefiles are used. 

Version three of MBDS uses the VMS operating system which does not have 
a makefile utility available. The VMS operating system provides command files, 
but they do not have the capability of tracking source-code modifications and 
dependencies. Therefore, to use command files for managing the implementation, 
not only must all of the makefiles be rewritten but the logic of their organization 
must also be changed. This 'means that MBDS version three requires over fifty 
command files to manage its implementation, more than twice the number of 
makefiles used by version two. Program modifications also take longer since it is 
easier to recompile and link all source-code files needed for a program (even 
unmodified ones), than to manually keep track of which have changed and what 
files are dependent on them. 

In order to avoid the problems caused by not using makefiles, an initial 
attempt has been made to utilize the EUNICE environment (on the VAX- 
11 /780). In EUNICE (a software system that emulates UNIX) makefiles can be 
used to compile programs which run on the VMS operating system. However, 
while the programs run on the VAX-ll/780 (with VMS) they prove to be not 
downward-compatible to the Micro-Vaxes, which are used for the MBDS back- 
ends. (The Micro- Vaxs are designed to be upward-compatible to the VAX- 
ll/780. but not vice versa.) Therefore, the makefiles had to be redone as com- 
mand files. 

The MBDS command-files are converted one set at a time, as each set is 
converted an attempt is made to compile the MBDS process. While it is known 
(because of the MBDS design) which files need changes, there is a desire to see if 
any unexpected compile-time errors might occur. No compile-time errors emerged 
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some warning messages have been generated because of variable names which con- 
tain too many characters. These are truncated by the compiler but do not cause 
any problems (the truncated length happens to be long enough to maintain 
uniqueness). Once each of the processes is compiled, what essentially exists is a 
version of MBDS with program segments executable on the VMS operating sys- 
tem. but still only able to communicate with each other using the UNIX commun- 
ication facilities. Obviously, the next step in the porting is to modify the source 
code which performs communications. 

As we stated in previous chapters, MBDS performs two types of communica- 
tion. intra-computer and inter-computer. With the UNIX operating system (used 
by MBDS version two) both types of communications are accomplished in the 
same manner. The VMS operating system (used by MBDS version three) uses 
different means to accomplish each of the two types of communication. The deci- 
sion is made to modify the MBDS communications software in two phases. In the 
first phase, an intermediate version of MBDS is created which utilized only one 
computing system, supporting both the controller and one backend. From a func- 
tional point of view, the controller and each of the backends does not know where 
the other components are executing. 

Since the intermediate version only used one computer, there is only a need 
to modify the intra-computer communications at that point. Version three of 
MBDS uses VMS mailboxes for intra-computer communications in the controller 
and backends (like the version one controller). For the intermediate version, the 
sections of code which normally perform inter-computer communications can call 
the same virtual communication interfaces as the intra-computer communications. 

When an attempt is made to test the intermediate MBDS version the first 
unexpected problems arise. After a considerable debugging effort the problem is 
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isolated to three lines of source code. The problem is ii<olated in the sense that it 
is known to occur in a particular line, but it is not obvious why it occurred. By 
all observ'ations the code is correctly written, and it has functioned properly, as is. 
in version two. Eventually, it is suggested that the code might be correct to the 
human observer but is being incorrectly interpreted by the compiler. The lines of 
code in question use some short-hand coding techniques, which has apparently 
complicated parsing them. The lines of code causing the problem looked like this 
(the problem areas are in bold); 

while (msg_q[(*index)] != 0) 

data[j++] = msg_q[(*index)+-h]; 

data[j] = msg_q[(*index)+-t-]; 

They are modified, to remove the short-hand techniques, resulting in the code 
shown below (note the need for two additional lines of code); 

i = *index; 

while (msg q[i] != 0) 

data[j-h-|-] = msg_q[i4-+]; 

data[j] = msg_q[i-h-l-]; 

*index = i; 

Once these changes are made the section of code functions properly, similar 
changes are needed in three other sections of the source-code. These are the only 
changes that have been required to get the intermediate version of MBDS working 
properly. 

The next step is to modify the inter-computer computer communications. 
Since the UNIX version does not have separate interfaces for inter-computer com- 
munications. these are not actually modifications. Instead, entirely new interfaces 
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must be created for \'MS inter-computer communications. MBDS version three 
uses DECNET software to perform the inter-computer communication. These 
interfaces (as well as the ones for the VMS intra-computer communication) are 
discussed further in the next section. After the inter-computer communication 
interfaces are completed the only task remaining is to perform some final testing. 
No additional modifications are necessary to create MBDS version three. 

B. THE MBDS COMMUNICATION INTERFACES 

Before proceeding further with any discussion of modifying the MBDS com- 
munication interfaces, we first present a general overview of the MBDS software 
architecture and how it utilizes the communication interfaces. As we have stated 
before, each MBDS implementation has a controller and one or more backends. 
The controller is comprised of six processes, and each of the backends has five 
processes. In a normal implementation the controller (i.e., its six processes) is run 
on its own computing system, there is also a separate computing system for each 
backend. Since each process is an independently run program it has no direct 
connection to any other process, yet the processes must pass messages (informa- 
tion and data) to each other for MBDS to operate. Within each process there are 
the virtual interfaces for sending and receiving messages, it is these send and 
receive routines which must actually be modified whenever MBDS is ported. The 
send and receive routines only perform the intra-computer communication. 

Of the six processes in the controller only four are needed by MBDS for data- 
base operations, the other two processes are used for inter-computer communica- 
tion. The same is true for each backend, that is, only three of the backend 
processes are used for database operations, the other two are for inter-computer 
communication. These processes (in the controller and each backend) operate as 
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the virtual interfaces for inter-computer communication To avoid confusion with 
the intra-computer interfaces we call these processes get-net and put- net (as 
opposed to send and receive). Excluding the get-net and put-net processes, all 
MBDS database-processes perform only intra-computer communication. The 
pseudocode for any MBDS database-process (at a very high level) looks like this : 

While MBDS is operating do 

Receive a message 

Perform any required processing 

Send any required response 

From looking at the pseudo code you might wonder how messages ever get from 
one backend to another, or from a backend to the controller. The answer is in the 
last line of the pseudo code, the key word is required. The required response may 
mean sending a message to more than one other process, if one of those processes 
is the put-net process then the message eventually goes to a process on another 
computing system. Therefore, the pseudocode for the put-net process looks like 
this: 

While MBDS is operating do 

Receive a message 

Put it to the appropriate process 

The appropriate process to which a message is put is always a get-net process on 
another computer system. The pseudo code for a get-net process looks like this: 

While MBDS is operating do 
Get a message 

send it to the appropriate process 

Now lets examine how the MBDS intra-computer communication interfaces (send 
and receive) have been modified to operate under the VMS operating system. 
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1. Modifying the Intra-Computer Communications 



The controller for MBDS version one uses the same AX-1 1/780 as the 
controller for MBDS version three. While version one runs on VXIS 3.7 and ver- 
sion three runs on VMS 4.2, the intra-computer communication facilities provided 
by the two VMS releases are the same. Therefore, the MBDS version one con- 
troller communication interfaces can be used for the MBDS version three con- 
troller without modifications, and can be used for the version three backends with 
only minor modification. 

In the VMS operating system, intra-computer communication is accom- 
plished with VMS mailboxes. These mailboxes are virtual devices which can be 
created through the operating system. When a program calls the operating sys- 
tem to create a mailbox, the program must specify a logical name to be assigned 
the mailbox. The operating system then creates a mailbox, with the specified 
logical name, and provides the program with a logical channel to the mailbox. 
Once a mailbox is created messages may be put into it (or taken out of it) by 
writing to (or reading from) the logical channel provided by the system. If a call 
is made to the operating system to create a mailbox with a logical name that has 
already been used, no new mailbox is created, the operating system just provides 
another logical channel to the already existing mailbox. This is how different 
processes on the same computer can communicate. If several processes all use the 
same logical name in a create-mailbox call to the operating system, then they all 
share the same mailbox. 

The MBDS intra-computer communication (using mailboxes) is accom- 
plished by having each process in the controller (or backend) create a mailbox 
with its own logical name, and mailboxes with the logical names for each of the 
other processes in the controller (or backend). The logical names are standardized 
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for all controller (and backend) processes. As we have said, if the same logical 
name is used more than once, multiple mailboxes are not created. Rather, only 
multiple channels to the mailbox with that logical name axe created. Therefore, 
when all processes in the controller (or backend) have finished with their create- 
mailbox calls, there is one mailbox for each process in the controller (or backend). 
Each process has a logical channel to its own mailbox, and logical channels to the 
other processes’ mailboxes. The protocol that MBDS uses to make this scheme 
work is that processes can only read their own mailboxes, and can only write to 
other processes' mailboxes. There is no need to write to their own. or read from 
any one elses. 

The MBDS version one controller's intra-computer communication 
software is used without changes for the controller in MBDS version three. To 
create the version three backend intra-computer communication software, it is 
only necessary to use a copy of the controller software with the controller logical 
names (for the mailboxes) changed to backend logical names. 

To create the intra-computer communications software for the inter- 
mediate MBDS version (i.e.. where the controller and backend run on a single 
computer together), one additional (temporary) change is made. An additional 
mailbox is created for the get-net and put-net routines in the backend and the 
controller. (Actually, only additional channels to existing mailboxes are created.) 
Normally, a controller process only has channels to mailboxes for controller 
processes, and backends only have channels to backend processes. For the inter- 
mediate version, put-net in the controller had a channel to get-net’s mailbox in 
the backend, and vice versa. This allowed the get-net and put-net routines to use 
the same virtual interfaces that are used by the send and receive routines (which 
perform all of the intra-computer communication). For the final version of 
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MBDS (version three), put-net and get-net no longer use mailboxes for communi- 
cation. This is because the VMS operating system does not allow logical channels 
to be established to a mailbox in another computer. 

2. Creating the New Inter-Computer Communications 

MBDS version three, like version two. uses Ethernet communication 
hardware to connect the controller to the backends (and the backends to each 
other). However, from a functional viewpoint, MBDS version three's inter- 
computer communication software operates more like MBDS version one (which 
used point-to-point communication hardware). This is because the way DECNET 
(VMS) communication software operates it does not provide a broadcasting capa- 
bility. DECNET is the operating system software used for the version three inter- 
computer communications. 

In the UNIX (Ethernet) environment all processes that wish to commun- 
icate simply associate themselves with the network, each process then has a logical 
communication link with all of the other processes that are associated with the 
network. (This is much the same as when processes under VMS associate them- 
selves with a common mailbox, for intra-computer communication.) However, in 
the DECNET (Ethernet) environment each process must establish a separate logi- 
cal link for every other process it wants to communicate with, therefore, this is 
essentially (software) point-to-point communication. 

When using the DECNET software, all processes which communicate 
with each other are either source processes, or target processes. A source process 
is one that initiates a request to establish a communication link with another 
process, the target process is the one that receives the request. A given process can 
be the target for a communication link with one process, and the source for a 
communication link with another. The DECNET software requires that a target 
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process is in execution before its source process requests the communication link. 
A requirement like this does not exist for inter-computer communication in 
MBDS version one. or version two (nor does it exist for intra-computer communi- 
cation. in any version). Therefore, the logic for the put-net and get-net processes 
in version three must be completely changed. 

In order to establish, and maintain, communication under the DECNET 
software the get-net and the put-net processes must operate under the following 
constraints: 

• any process which is a target must be executing before its source process 
attempts to establish communication. 

• if a process is to have multiple communication links, where it is a target in 
some cases, it must be capable of maintaining communication on established 
links, while still waiting for (or accepting) any links where it is the target, 

• a target process must inform the operating system (through DECNET) of 
the network name it is using, so that DECNET can properly route connec- 
tion requests, 

• a source request must know the network name for all of its target processes, 
and it must know the name of the computer (the nodename ) that each tar- 
get executes on. 

• a process must know the total number of communication links it should 
have, how many it is ; target for. and how many times it is a source. (This 
is because MBDS conhgures the number of backends to be used, on-the-fiy. 
when it is started.) 

Now let us review how the get-net and the put-net routines for MBDS version 
three were organized to meet these criteria. 

In the MBDS controller, both the get-net and the put-net processes are 
always source processes. Therefore, when MBDS is initially started, the controller 
processes are executed after all of the backend processes are executed. This 
satisfies the target/source ordering for the controller-to-backend communication. 
As soon as the controller is informed (by the user) how many backends are to be 
used the get-net and the put-net routines can begin establishing (requesting) com- 
munication links. Since the controller (get-net and put-net) communication 
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routines are never targets, they do not have to inform DECNET of any network 
names (they do not need network names). Also, since they are never targets, they 
do not have a requirement to accept a connection request while communicating 
(they never accept connection requests). When requesting the communication 
links, get-net and put-net know the names of the processes they communicate 
with because the MBDS process names are standardized. In order for them to 
know the computer systems (nodenames) that the backends are executing on, the 
nodenames are standardized as well. 

Each nodename consists -of a character string that ends with a number 
(e.g.. CSMVl. or CSMV2), only the numbers at the end are different. The con- 
vention used by MBDS is that, if only one backend is used, it is on the computer 
with the lowest nodename (i.e., CSMVl). if multiple backends are used they are 
on the computers with the lowest consecutive nodenames (e.g.. for three backends: 
CSMVl, CSMV2, and CSMV3). As soon as the controller routines know the 
number of backends, they can construct the proper nodenames. 

For the MBDS backend-to-backend, inter-computer communication the 
backend get-net processes are always targets, and the backend put-net routines 
are always the source. Remember that backend put-net processes are targets for 
controller-to-backend communication, they are the only processes which perform 
both as targets, and sources, depending on the situation. Since there is always a 
single controller, the backend put-net process knows it is a target for a single com- 
munication link. The backend put-net process does not begin requesting links 
(acting as source) to the other backends get-net processes until after it has 
received its first message from the controller. By convention, this first message is 
always the number of backends to be used. The put-net process then knows how 
many communication links it must have, and where it is the source. The put-net 
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process forwards this message (using the intra-computer communication) to its 
respective get-net process and then the get-net process knows how many times it 
must act as a target for a communication link. The backend put-net routines 
determine nodenames (for the other backends computer systems) in the same 
manner used by the controller. When the backend get-net and put-net routines 
are first executed, they inform DECNET of the (standardized) network names 
that are being used. 

Because the backend communication processes (get-net and put-net) act 
as target tasks with multiple communication links, they must be capable of main- 
taining the communications on any established links while waiting for (or accept- 
ing) connection requests. They accomplish this by using VMS mailboxes, these 
are the same types of mailboxes used for intra-computer communication. How- 
ever. in this case, the mailboxes are not used for MBDS messages, but are used for 
DECNET status information. When a process uses DECNET to perform com- 
munication it establishes a logical link to DECNET. This is in addition to the 
logical links for the other processes that it communicates with. Any time a pro- 
cess establishes a logical link, the process has the option of associating a mailbox 
with that logical link. One mailbox may be associated with multiple links. 

If a communication link has a mailbox associated with it, DECNET 
places network status messages (about that link) into the mailbox. These status 
messages may include information such as the fact that DECNET has a connec- 
tion request for a process, the fact that an established link has received a message, 
or the fact that a process on the other end of a communication link has discon- 
nected itself. Therefore, the backend communication processes can handle multi- 
ple links by associating a single mailbox with all of their communication links. 
Each time the process completes an operation (e.g., putting a message, getting a 
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message, or accepting a connection request) it then reads its mailbox. The next 
message in the mailbox determines what operation the process must perform next. 
DECNET automatically queues multiple messages in the mail box. If a process' 
mailbox is empty the process waits until a message arrives, that is, an empty 
mailbox means there is nothing else for a process to do. 

Mailboxes are used for managing multiple connections by all of the 
MBDS inter-computer communication processes which act as targets, or as 
message-receiving processes. Therefore, the put-net process in the controller is the 
only one that does not need a mailbox to manage its communications (it is never 
a target, and only puts messages). By convention, any time a process puts an 
inter-computer MBDS message to another process it also puts a DECNET 
notification message to the same process (these are optional with DECNET, and 
not generated automatically). The MBDS message goes on the logical communi- 
cation link, and the notification message is placed (by DECNET) into the mailbox 
for that communication link, at the receiving process. If the DECNET 
notification message were not sent the receiving process would never be prompted 
to look at the communication link for a message. 
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V. SUMMARY AND CONCLUSIONS 



In this thesis we have focused on three major areas of work. First, a para- 
digm for a software system has been presented, and we have examined how the 
components in the paradigm relate to the portability of the software system. Let 
us review the general issues of software portability discussed in the previous 
chapters. We have presented a paradigm for a software system which shows that 
there are two main components to any software system, the system source code 
and the operatings system commands used by the software system. Each of these 
main components has additional sublevels. For the system source code there are 
the sublevels of machine code, assembler language and high-level code. The sub- 
levels of operating system commands are, basic commands, command files, and 
utilities. We have also stated that there are three parts to a computing environ- 
ment which a software system interacts with, the hardware, the translator (used 
by the source code for the software system) and the operating system. Finally, we 
have stated that, the components of a software system interact with the parts of 
its computing environment through three types of processing, basic processing, 
translator environment processing, and runtime environment processing. 

Our analysis showed that the ease with which a software system reacts to 
porting is determined by three factors; 

• the levels of system source code and operating system commands used to 
construct the system. 

• the types of processing which the software system performs, and 

• the parts of the computing environment which are changed. 
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In general, a software system is highly portable if it uses only high-level code, and 
if it avoids runtime environment processing whenever possible. 

The second focus of the thesis has examined how well the MBDS software 
stands up to porting. To construct its three versions, the MBDS software has 
been subjected to all three types of porting. Each time the system was ported, 
MBDS ran on new hardware, had a new operating system and had a new transla- 
tor for its system source code. Despite the drastic changes in its environment, 
MBDS performed extremely Well each time it was ported. In neither case did the 
fundamental MBDS design require modification. This can be attributed to several 
factors. First, the MBDS software is written entirely in high-level code and the 
use of runtime processing has been avoided except where absolutely necessary 
(e.g., communications and disk input /output). Additionally, any processing 
which might complicate portability has been buffered in MBDS through the use of 
abstraction, encapsulation and virtual interfaces. 

The third focus of the thesis has involved the details of the MBDS porting. 
The major work of porting MBDS has involved modifying the sections of code 
which create the virtual interfaces. The interfaces themselves have not been 
changed, only the way in which the interfaces accomplished their jobs are 
modified. These changes have involved the MBDS communication software. For 
the inter-computer communications, the MBDS version one software has been 
modified to create MBDS version three. This intra-computer communication is 
accomplished using VMS mailboxes. For the inter-computer communications, 
entirely new communication software has been created in MBDS version three. 
The VMS DECNET communication drivers are utilized for the inter computer 
communications. (Source code for the new inter-computer communication 
software is contained in the appendixes to the thesis.) 
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In addition to modifying the communication interfaces, creating MBDS ver- 
sion three has also required modifying all of the operating system command files 
used to manage the software. This involved rewriting the UNIX makefiles (from 
MBDS version two) as VMS command procedures (for MBDS version three). 
Rewriting the command files has been the most time consuming task in the port- 
ing process. 

Overall. MBDS has proven to be easily portable. With the exception of some 
minor problems caused by the way the new compiler parsed some lines of code (in 
MBDS version three), all of the modifications required to port MBDS have been 
known before the porting began. Additional information on the portability of 
MBDS can be found in [Ref. l] which deals with the process of porting MBDS 
version one to MBDS version two. 
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APPENDIX A - THE MBDS CONTROLLER GET-NET SOURCE CODE 



r V 

/^ VAX/ VMS G_PCLC */ 

r V 

^* + ***********************:*:*** + * + *********y 



i nc 1 ude 


<s t d i o . h> 


/* 


Standard I/O definition 


V 


# i nc 1 ude 


<s s de f . h> 


/* 


VMS return status codes 


V 


f i nc 1 ude 


< i od e f . h> 


r 


AMS I/O return codes 


V 


# i n c 1 ude 


<ms gde f . h> 


r 


DECNET ms g definitions 


V 


# i nc 1 ude 


<dvidef.h> 


r 


AMS device definitions 


V 


# i nc 1 ude 


" c onind a t a . d e f 


n 


j* MBDS common defs 


V 


# i nc 1 ude 


"ms g . de f " 




/* MBDS msg-type defs 


V 


# i nc 1 ude 


" flags. de f " 




/* MBDS compile flags 


*/ 


fde fine 


MAXBE 16 




j* max num of backends 


V 


char n e 


tbuf [MSGLEN] ; 




/* network buffer 


*/ 


char mbxbu f [MSGLEN] ; 




/ ma ilbox buffer 


V 


char ms 


g [MSGLEN] ; 




/ ’^ MBDS -ms g buffer 


V 


short net chan: 




/* channel to DECNET 


V 


short mbx chan: 




/* channel to ma ilbox 


V 


short be 


chan [MAXBE -1- 


1 


] ; /* chan's to backends 


*/ 








j* backend 0 is not used 




short be 


de V [MAXBE 4- 


1) 


; / ” device num of chans 


*/ 


short NoBackends; 




! the num of backends 


*/ 



Struct 



ms g hdr head; 
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ma in ( ) 

{ 

inf i. /'loopindex "/ 

StopSys: /’ system running flag */ 



char NoBEs [NoBElength + l] ; 



/* init intra-c omp u t e r c orrmu nication */ 
mb i n i t ( G PCLC ) ; 



ififdef EnExFlag 

pr int f ( "Enter GPCL\n" ) ; 

^end i f 

j* get the number of backends */ 

#ifdef pr flag 

p r i n t f ( "Ge t t i n g number of bac kends \ n" ) ; 

# e nd i f 

receive(msg. &head): 

^ifdef pr flag 

m_p r n t ( ms g . &h e a d ) ; 

=^end i f 



if (head.tvpe != SetNoBEs) 

{ 

printf("** Error in GPCLC . first ms g must be ") 
printf("of type SetNoBEs **\n"); 
printfl"*"*^ Type = %d **\n". head. type); 
m p r n t ( &ms g . <kh e a d ) ; 
sleep (DELAY) ; 
e X i t ( ) : 

} 



/ Extract the number of backends */ 

for ( i =0 : ( ( NoBEs [ i ] = ms g [ i ] ) I = ' \ 0 ' ) : i ++) : 



NoBackends = s t r _t o_num( NoBEs ) : 



fifdef pr flag 

p r i n t f ( "Numb e r of backends= %d\n", NoBackends) 

# e nd i f 
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/ "■ Init network connections to P PCL ’ s 
net i n i t ( NoBack ends) : 

StopSys = FALSE: 
wh ile ( !StopSvs ) 

{ 

get _tne s s a g e ( ms g . &h e a d ) ; 



sw i t c h 

{ 



(head. type ) 



/* ms g type for ms g s from DMg t (BEnds) to 

c a s e (Re qFo rNewDe s c I d ) : 
head. receiver = IIG: 
break : 



case(ClusId) : 
head. receiver = IIG; 
break ; 

I* ms g type for ms g s from RecP (BEnds) t 

c a s e ( BC_Re s ) : 
head. receiver = PP ; 
break ; 



case(BC AO Res) : 
head. receiver = PP ; 
break ; 



/* ms g type for ms g s from RecP (BEnd.«) to 

case (RetFetCause dByUpdRe s ) 
head. receiver = REQP ; 
break : 



c a s e ( Re cCh ang edC 1 u s ) : 
head. receiver = REQP : 
break ; 



case( NoMoreGenIns ): 
head. receiver = REQP : 
break ; 



in backends '/ 



IIG (ct 1 1 er ) */ 



PP (cnt r 1 ) * ! 



ReqP (cntrl) */ 
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/■ ms g type for ms g s froniBEnds to TI (ctller) ‘ j 

case(Error): 
head. receiver = TI: 
break : 

case(ErrorFree) : 
h e ad . r e c e i V e r = TI ; 
break ; 

case (GeTime s ) : 
head. receiver = TI; 
break ; 

case ( T i m_A r r _Emp ) : 
head. receiver = TI: 
break ; 

case (Stop) : 

StopSys = TRUE : 
break ; 

default: 

■ p r i n t f ( " I n V a 1 i d me s s a g e type " ) : 
pr intf ( "encountered : %d n" ,head. type) 
exit 'graceful ly(): 

} / end swi t c h * / 

if ( IStopSys ) 

{ 

head. sender = G PCLC; 
s e n d ( ms g , &h e a d ) ; 

iifdef pr flag 

m p r n t ( ms g , &h e a d ) : 

= end i f 

} 



} / end wh i 1 e * / 



^ i f d e f 
ite nd i f 



EnExF 1 ag 
p r i n t f ( " Ex i t 



} 



GPCL\n" ) ; 
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routine to get the next message from the network 



/ ■ 

/ 

get me s s a g e ( mp t r . h p t r ) 

char * mp t r : 
struct msg_hdr *hptr; 

{ 

i n t s t a t . 

ms glen, 
f un c , 

j , k ; 

short iosb[4] ; 
char r c vbu f [MSGLEN + l] , 
intbuf [ 2] = "\0" , 

tmp s t r [ 5 ] : 

short ms g r e c ; 

#ifdef EnExFlag 

printf(" Enter get _me ssage\n") : 

f end i f 

/* ’Check mailbox for message notices */ 
read mb x ( mb x b u f ) ; 



/ * Re ad the 


me s s a g e * / 


read net(rc 


vbu f . mbxbu f ) ; 


/ Ge t the 


header information " / 


k=0 ; 


/* get sende 


r V 


for ( j =0 ; j 


< 3 ; j -H-) 


tmp s t r [ j 


] = r c vbu f [ k-H-] ; 


tmp s t r [ j ] = 


’ \ 0 ■ : 


hptr->sender 


= s t r to num( tmp s t r ) ; 


/ get receiver * / 


for (j=0: j 


< 3 ; j -H-) 


tmp s t r [ j 


] = r c vbu f [ k-H-] ; 


t mp s t r [ j ] = 


’ \ 0 ’ ; 


hptr->receiv 


er = str to num(tmpstr) 



52 



! ’ get the type '/ 
for (j=0: j < 3; j-hf) 

tmp str[j] = rcvbuf[k -H- ] ; 
tmp s t r [ j ] = ' \ 0 ' : 

hptr->type = s t r _t o_num( tmp s t r ) ; 

iifdef pr_flag 

m_p r n t ( r c vbu f . hptr); 

^end i f 

j copy the me s s a g e * j 
j=0; 

while ( (k < MS GLEN) (rcvbuf[k] != EOvls g ) ) 

mptr[j++] = r c vbu f [k-H-] ; 

mp tr[j] = rcvbuf[k]; f * get ECMs g * / 

if (k >= MSGLEN) 

pr int f ("**** " Value o f MSGLEN "); 
printf( "should be increased ****^\n"j; 

# i f d e f EnExF 1 a g 

p r i n t f ( " Ex it get _me s s a g e \ n " ) ; 

= end i f 

} /* end get me s s a g e * / 
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/’ Routine to check the ma i 1 b o x for me ssage notices ’/ 

read mb x ( b u f ) 

char *buf; 

{ 

short ms g r e c ; 
sho r t s t at ; 
short iosb[4] ; 

^ifdef EnExFlag 

p r i n t f ( " En ter read _mb x \ n " ) : 

if e nd i f 



msg rec = FALSE; 

wh i 1 e ( ! ms g _r e c ) 

{ 

#ifdef pr_flag 

printf(" Cal ling qio, read ma i 1 box \ n " ) ; 

#end i f 

stat= sys$qiow(0, mbx_chan, IO$_READVBLK, 

iosb, O.OT buf, MSGLEN, 0.0. 0.0); 

#ifdef pr_flag 

p r i n t f ( "Re t u r n e d from qio \n"): 

# e nd i f 

if ((stat != S S $ _NORM.\L ) || (iosb[0] != S S $ _NORVL\L ) ) 

{ 

p r i n t f ( " * * Ma ilbox read error. stat= %d ( %x ) . " ) ; 

printf("iosb[0]= %d ( %x ) **\n", stat. stat. 

iosb[0], iosb[0]); 



exit 


graceful ly() 


} 




sw i t c h 


(buf [0] ) 


{ 




case 


MSGS INIMSG; 



{ 

ms g _ r e c = TRUE ; 
break ; 

} 
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case 



MSGS _COXXECT : 

/ 

L 

printf("'‘' Nei wo rk connection "): 
printf(" requested n") ; 

p r i n t f ( " * * GPCLC should not "): 
print(" receive connect req's ** n 
exit gracefullv(); 

} 



case MSGS CONFIRM: break: 



default: 



} / * end switch 

} / * end wh i 1 e * / 



{ 

printf("** Net wo rk error, "): 
p r i n t f ( "mbxbu f [ 0 ] = %d (%x) **\n", 

buf[0], buf[0]) 

exit gracefully(): 

} 

*1 



i f de f EnExF 1 ag 

p r i n t f ( " Ex it read mb x n " ) ; 

e nd i f 



/* end read_mbx */ 
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/' Routine to read a message from a backend */ 

read net (rcvbuf. mb x b u f ) 

char *rcvbuf. mb x b u f ; 

{ 

short ’*^unit, 

BEnum, 
f un c , 
s t a t , 
i o s b [ 4 ] ; 

fifdef EnExFlag 

p r i n t f ( " En t e r r e a d n e t \ n " ) : 

^end i f 

u n i t = mb x b u f : 

for ( BEnum = 1 : be _de v [ BEnum] ! = un i t [ 1 ] ; BEnum-H-) 

{ 

if (BEnum = NoBackends) 

{ 

printf( Cannot locate unit n umb e r to V ) ; 

print("read net with. ***\n"); 

printf(”*** Searched through %d backends . ") : 
printf(" *** BEnum): 

exi t_g raceful ly( ) : 

} 



fifdef pr flag 

printf(" Calling qio read fr om backend %d '' n " . BEnum) ; 

#end i f 

func = IO$_READ\'BLK; 

stat= sysSqi ow ( 0 , be chan] BEnum] . func. i o s b . 

0.0. rcvbuf, MSGLEN. 0.0. 0,0) 

#ifdef pr flag 

printf(" Returned fr om q i o \ n " ) ; 

#end i f 
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if ((star 1= SS$ XORNL\L ) | | ( i o s b 0 ] 1 = S S $ NORMAL i 1 

{ ■ ■ ' ■ ~ 
printf("'* Read error be_chan /cd . s t a t = %d (%x ) , " ) 

printf("iosb[0] = %d(%x) * n". BEnum. stat. 

stat. iosb[0] . iosb[0]) 

exit_gracefiil ly() ; 

} 



fifdef EnExFlag 

p r i n t f ( " Ex it r e a d _n e t \ n " ) ; 

f end i f 

} /* end read net * / 
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/’ Routine to initializ Dec net links to each backend ' j 
net i n i t ( NoBEs ) 



i n t NoBEs : 

{ 

i n t s t a t , i ; 
short iosb[4| ; 

char nodespec[l28] . tmp s t r [ 5 ] ; 



struct sd { 

i n t 1 en ; 

char ’■ptr; 

} 

n e t n am = { 5 , " _NET : " } , 

neb = { 0, nodespec }. 

netmbx = { 6. "NET!\4BX" }: 

long dviunit[l]; 

short dviunit len[l]: 



j * structure to get unit n umb ers for chan’s to net */ 
struct { 



short 


1 e n : 


/* 


buffer 


1 eng t h 


V 


short 


code; 


/* 


i t em c 


ode 


V 


1 ong 


un i t ; 




addr to return uni 


t to*/ 


short 


* un i t 1 e n 


•• /* 


1 e ng t h 


of unit 


V 


1 ong 


nu 1 ; 


r 


end of 


descriptor 


V 


) 

dv i = 


{4. DVI$_ 


UNIT, 


dv i un 


it. dv i un i t 


1 e n , 0 } ; 



# i f de f EnExF 1 ag 

p r i n t f ( " En ter n e t i n i t \ n " ) ; 

#end i f 



I * create a ma i 1 b o x * / 

s t a t = s y s $ c r embx ( 0 . &mbx chan. MSGLEN . MSGM4X, 

0 , 0 , &n e t mb x ) : 

if ( stat != SSS_NORMAL) 

{ 

printf("** Error creating ma i 1 b o x , " ) ; 

printf ("stat= %d ( %x ) "’"*\n", stat, stat); 

exitgraceful ly() ; 

} 
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j ' assign channels to the net ’/ 
for(i=l: i <= NoBEs : i-i-+) 

{ 

stat= sys$assign( &n e t n am , &b e c h a n [ i ] . 0 . &n e t mb x ) ; 
if (stat !=SS$ _NORMAL ) 

{ 

printf("** Error in assign be chan %d , " ) ; 

printf("stat= %d ( %x ) **\n", 1, stat. stat): 

exit _g raceful ly() ; 

} 

} / * end for i * / 

/* Establish logocal link */ 
for(i=l; i <= NoBEs ; i-H-) 

{ 

/* build network connect block */ 

strcpy(nodespec. "CSMV ) ; 

num to str(i, tmpstr); 

strcat (nodespec, tmpstr): 

strcat (nodespec, " : : \ " 0=PPCLB' " " ) ; 

l^ifdef pr flag 

printf ("backend %d node.spec, \"%s\"\n", i. nodespec): 
f end i f 

ncb.len= strlen(nodespec); 

/* Request the connection */ 

s t a t = s y s $ q i ow ( 0 , be c h an [ i ] , 10$ ACCES S . i o s b . 

0,0,0, &ncb. 0.0, 0.0) 
if ((stat != SS$_NORMAL) || (iosb[0] ! = S S $ _NORM.A.L ) ) 

{ 

printf("** Ac cess err<r be chan %d , s t a t= %d " ) : 
p r i n t f ( " ( %x ) . i o s b [ 0 ] = %d ( %x ) **\n". i, stat, 

stat. iosb[0], iosb[0]); 

exit graceful ly(): 

} 

} /* end for i * j 
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/' Get unit numbers for the channels ' j 
for(i=l; i <= XoBEs : i-l— f) 

/ 

i 

stat= sys$getdvi(l. be chan[i], 0. &dv i . iosb. 0,0.0) 

if (stat != SS$_NORM.A.Ly 

{ 

p r i n t f ( '* * * Error getting channel number for BE " 
p r i n t f ( ”%d . s t a t = %d { %x ) **\n". i, stat, stat); 

exit _g raceful lv() ; 

} 

s y s $wa i t f r ( 1 ) ; 

if (iosb[0] := SS$_NORMAL) 

.{ 

printf("** Error getting channel number for "); 
p r i n t f ( " BE %d , i o s b [ 0 ] = %d ( %x ) * * , n " . i . 

iosb[0). iosb[0]); 

exit_gracefully(); 

} 

be dev[i] = *dviunit; 

} /* end for i */ 

^ifdef EnExFlag 

printf(”Exit net_init\n"); 

#e nd i f 

} / * End net i n i t * / 
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/■ routine to disconnect 



all ne two r k links ' j 



disconnect () 

{, 

i n t s t a t , i : 

T&ifdef EnExFlag 

p r i n t f ( " En ter Disconnectin'') ; 

T^end i f 

for (i=l: i <= NoBackends; i-H-) 

{ 

^ifdef pr_flag 

printf(" Disconnecting backend %d in", i ) ; 

#end i f 

stat= s y s $ d a s s gn ( b e chan[i]): 
if (sta't != SS$_NOR]^L) 
printf("** Das sign Error for backend %d , "); 

printf("stat= %d ( %x ) **\n".i.stat. stat): 

} 

#ifdef EnExFlag 

p r i n t f ( " Ex it Disconnect \n"); 

#end i f 

} / * En d disconnect * / 



/* Routine to close network connections, then abort */ 



exit graceful lv() 

{ 

s leep( DELAY) ; 
disconnect() ; 
ex i t ( ) ; 

} 
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APPENDIX B - THE MBDS CONTROLLER PUT-NET SOURCE CODE 



! ^ ^ ^ 








r 




*! 




r 


V A X / V M S 


P P C L C * ! 




r 




*1 




j if. if if 


ififi^ifiici^if:i\^ififififiic:^ififif 






^ i n c 1 ud e 


<stdio.h> /* 


Standard I/O definition 


V 


# i n c 1 ud e 


<s sde f . h> / * 


VMS return status codes 


V 


^ i n c 1 ud e 


<iodef.h> / * 


\MS I/O return codes 


V 


i n c 1 ud e 


<ms gdef.h> / * 


DECNET msg definitions 


V 


# i n c 1 ud e 


" c orrmd a t a . d e f " 


/* AIBDS corrmon defs 


V 


# i n c 1 ud e 


"ms g . de f " 


/ " MBDS msg- type defs 


V 


1 ud e 


"f lags .def" 


/* MBDS compile flags 


V 


# i n c 1 ud e 


"beno.dc 1 " 


/* backend num decl 


V 


^de fine 


MAXBE 16 


! max num of backends 


V 


^de fine 


TRUE 1 






#de f i n e 


FALSE 0 






char 


netbuf [MSGLEN] ; 


j* network buffer 


V 


char 


msg [MSGLEN] : 


/* MBDS -msg buffer 


V 


short 


be chan [MAXBE -h 1 


] ; /* chan’s to backends 


V 






/* backend 0 is not used 


V 


short 


be dev[MAXIBE -1- l] 


; /* device num of chans 


V 


short 


NoBac Lends ; 


/* the num of backends 


V 


struct 


ms g hd r head; 


• 
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ma in ( ) 

{. 

int StopS}’s.i.j.k: 

char XoBEs [ NoBE 1 e ng t h + 1 ] : 

fifdef EnExFlag 

pr int f ( "Enter PPCL\n" ) ; 
4:end i f 



/* init intra-c omp u t e r c omnu nication */ 

mb i n i t ( P PCLC ) ; 

/* receive a message from a controller */ 

/* task into ppcl's ma i 1 b o x * / 

r e c e i V e ( &ms g [ 0 ] , &h e a d ) ; 

/* The first message should type SetBEno. */ 
if( head. type != SetNoBEs ) 

{ 



printf( "Error in PPCL . 1st message "); 
p r i n t f ( "mu s t be of type SetNoBEs" ); 
printf( " Type = %d \n", head. type ); 
ms e n d ( &ms g [ 0 ] . &h e a d ) : 
abo r t ( ) ; 

} 

/* send num of BE to GPCLC */ 
head. sender = P_PCLC ; 
he ad . r e c e i V e r = G PCLC; 
s end (^jns g [ 0 ] . <S;head) ; 

/* Extract the NoBackends */ 

f o r ( k=0 , j =0 ; (NoBEs [ j ] = ms g [ k ] ) ! = ’ \ 0 ' ; 

k+- 1- , j -l— l- ) ; 

NoBackends = str to num( NoBEs ) : 
k+-f : 

/* Initialize connections to backends */ 
net i n i t ( NoBac k e nd s ) ; 

/* send BACKENT) NO and NoBackends to backends 
/* Change the message type * j 
head. type = SetBEno: 
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/’ send the ms g to each BE * j 

for (i=l; i NoBackends; i = i -h 1) 

{ 

/* Put the backend number into message ^ j 
len num_to_str( (i). NoBElength, <Smis g [ k ] ) 

ms g [ k + NoBElength +1 ] = EOMs g ; 

j* send the msg to the specified BE */ 

h e ad . r e c e i V e r = G_PCLB; 

put me s s a g e ( ms g , <kh e a d . i ) : 

} 

/* receive me s s a g e f r om a controller */ 

/* task into ppcl’s mailbox */ 

receive ( &ms g [ 0 ] , &h e a d ) ; 

StopSys = FALSE; 
wh ile ( IStopSvs ) 

{ 

/* send the msg to each BE */ 

for (i=l; i <= NoBackends; i = i + l) 

{ 

/* send the msg to the specified BE */ 
put _me s s a g e (ms g . <Sih e a d . i ) ; 

} 

if ( head. type = Stop ) 

StopSys = TRUE ; 

else 

/* receive the next me s s a g e * j 
get me s s a g e ( &ms g [ 0 ] . &:h e a d ) ; 

] j * end wh ile * / 

exit graceful lv(): 

} 
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routine to send me ssage over netw'ork to a backend '/ 



p u t _me ssage ( mp t r . h p t r . BEn um) 

char *mp t r ; 
struct msg_hdr *hptr; 
int BEnum; 

{ 

int s t a t . 

ms glen, 
f unc . 
j , k ; 

short iosb(4] ; 

char sndbuf [MSGLEN +1], 

intbuf [2] = "\0" , /* null 

tmp s t r [ 5 ] ; 



f i f de f EnExF 1 ag 

printf(" Enter put message\n 

*end i f 

hptr -> sender = P_PCLC ; 
hptr -> receiver =G PCLB ; 

k=0 ; 

I* copy header into message to 

len num to str(hptr->sender, 3 
for (j=0; j < 3; j-H-) 

sndbuf ( k++] = tmps t r [ j ] ; 

len num to str(hptr->receiver. 
for‘(j=0; j < 3; j -H-) 

•sndbuf [ k-H-] = tmp s t r [ j ] ; 

len num to str(hptr->type, 3, 
for (j=0; j < 3; j-H-) 

sndbuf(k-H-] = tmpstr[j]; 



me ssage * j 






be sent */ 
tmp s t r ) : 



3 . tmp s t r ) ; 



tmp s t r ) ; 
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/" copy the me s s a g e ’ / 

j =0 : * 

while ( (k < MSGLEN) 

( ( s n d b u f [ k -I— I- ] = mp t r [ j -H- ] ) 1 = ECMs g ) ) : 



if (k >= MSGLEN) 

printf( "***** Value of MSGLExX "); 
printf(" should be increased *****\n"); 

ms glen = k ; 

/ * send the me s s a g e * / 

#ifdef pr flag 

p r i n t f ( "Ca 1 1 i ng qio write to backend %d\n", BEnum) 
m prnt(sndbuf, hptr); 

#e : d i f 



func = IO$_WRITE\'BLK; 

stat= sysSqi ow ( 0 , be c h a n [ BEn um] , func, iosb. 0,0, 

sndbuf. msglen, 0,0, 0,0) 

#ifdef pr_flag 

p r i n t f ( "Re t u r n e d from qio, write\n"); 

e nd i f 

if ((stat := SS$_NORMAL) I I ( iosb[0] ! = S S S _NORMA.L ) ) 

{ 

printf Wr ite error be chan %d , s t a t = %d " ) ; 
p r i n t f ( " (%x ) , iosb[0]= %d (%x) **\n", BEnum. 

stat, stat. iosb[0], iosb[0]) 

exit gracefully(): 

} 



/* let receiver know ms g is there */ 

#ifdef pr_flag 

printf(" Cal ling qio, interrupt \ n"): 

fendi f 

func = IO$_WRITE\'BLK | lOlM INTERRUPT ; 

stat= sys$qiow(0, be chan[BEnum] , func, iosb, 0,0, 

intbuf, 1, 0,0, 0,0) 
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=ifdef pr flag 

p r i n t f ( " Re turned fr om qio. interrupt n"): 

-e nd i f 

if ((stat !=SS$ _NORMA.L ) |1 (iosb(0] :=SS$ NORMAL ) ) 

{ 

printf("** Interrupt error b«- chan %d . "); 

printf("stat= %d ( %x ) , i o s b [ 0 ] = %d ( %x ) * * \ n " , 

BEnum, stat. stat. iosb(0], iosb[0]): 
exit _g raceful ly() ; 

} 

fifdef EnExFlag 

p r i n t f ( " Ex it put _me s s a g e \ n " ) ; 

f end i f 

} 
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/’ Initializes Decnet links to each of the backends '/ 
net i n i t ( NoBEs ) 
i n t NoBEs ; 



i n t s t a t . i ; 
short iosb[4] ; 

char nodespec[l28] . tmp s t r [ 5 ] ; 

struct sd { 

i n t 1 eri ; 
char ’'ptr 

} 

n e t n am = 
neb = 

# i f d e f EnExF 1 ag 

p r i n t f ( " En ter net init\n"); 

T^end i f 

for(i=l: i <= NoBEs: i-H-) 

{ 

/* assign a channel to the net */ 

stat= sys$assign( &n e t n am . &:b e chan[i]. 0. 0); 

if (stat != SS$_NORMAL) 

{ 

printf("** Error in assign be chan %d . " ) ; 

printf("stat= %d ( %x ) 1. stat. stat); 

exi t_graceful ly( ) ; 

} 



/ * Establish logocal link * / 
for(i=l: i <= NoBEs: i-H-) 

{ 

/* build network connect block */ 

strcpy(nodespec. "CSMV''" ) ; 

num to s t r ( i , tmp s t r ) ; 

streat (nodespec. tmp s t r ) ; 

streat (nodespec. 0=GPCLB\ " " ) ; 



{ 5 , " _NET : " } , 

{ 0, nodespec }; 
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n". i. nodespec): 



-ifdef pr_flag 

printf(" backend %d nodespec. "%s 
iend i f 

ncb.len= s t r 1 en ( node spe c ) : 

1^ Request the connection / 
stat= sysSqi ow ( 0 . b e_c han [ i ] , 10$ _ACCES S , i 

0,0,0, <S^n c b , 

if ((stat := SS$_NORMAL) 1| (iosbjo] !=SS$ 

{ 

printf("** Access error be chan %d , stat 
p r i n t f ( " ( %x ) , • i o s b [ 0 ] = %d ( %x ) * * \ n " , i , 

stat, iosb[0], i 

exit_graceful ly() ; 

} 

} / * end for i */ 

iifdef EnExFlag 

p r i n t f ( " Ex it net i n i t \ n " ) : 

#end i f 

} 



o s b . 

0 . 0 . 0 . 0 ) ; 
_NORMAL ) ) 

= %d " ) ; 

stat , 
osb [ 0 ] ) ; 



69 



j' routine to disconnect all network links */ 

disconnect() 

{ 



i n t s t a t , i ; 

#ifdef En Ex Flag 

p r i n t f ( " En ter Disconnect\n"): 

^ end i f 

for (i=l; i <= NoBackends; i-H-) 

{ 

#ifdef pr_flag 

printf( "Disconnecting backend %d \ n " , i ) ; 

#end i f 

stat= sysSdassgnfbe chan[i]); 
if (stat != SS$_NORM\L) 
printf("'*^* Das sign Error for backend %d , "); 

printf("stat= %d ( %x ) **\n",i,stat, stat): 

} 

# i f d e f EnExF 1 ag 

printf("Exit Disconnect \n") : 

#end i f 

} /* end disconnect */ 



I* Routine to close network connections, then abort */ 

exi t_g raceful ly( ) 

{ 

sleep) DELAY ) : 
disconnect)) ; 
exit)) ; 

} 
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APPENDIX C - THE MBDS BACKEND GET-NET SOURCE CODE 



/■ ’/ 

r VAX/VMS G PCLB */ 

/* */ 



fine 1 ud e 
fine 1 ude 
fine 1 ude 
^ i ne 1 ud e 
fine 1 ud e 
§inc 1 ud e 
f i ne 1 ude 
i n e 1 ud e 
#d e f i n e 



< s t d i o . h> 

<s s de f . h> 

< i ode f . h> 

<ms gd e f . h> 

<dv i d e f . h> 

" e onmd a t a . d e f " 
"msg .def " 



r 

/* 

r 

r 

/* 



"flags 

MAXBE 



def" 

16 



Standard I/O definition 
VMS return status eodes 
VMS I/O return eodes 
DECNET ms g definitions 
VMS deviee definitions 
/* MBDS eonrnon defs 
/* MBDS msg- type defs 
/ * MBDS e omp i 1 e flags 
/* max num of baekends 



V 

V 

V 

V 

V 

V 

V 

V 

*/ 



ehar ne t bu f [MSGLEN] 

ehar mb xbu f [MSGLEN] 

ehar msg [MSGLEN] ; 



/* network buffer */ 
/ * ma ilbox buffer *'/ 
/* MBDS -msg buffer */ 



sho r t net ehan ; 

short mb x ehan; 

short be ehan [MAXBE -H 1 

r 



/ * ehannel to DECNET 
/* ehannel to mailbox 
; I * ehan’s to baekends 
baekend 0 is eontroller 



V 

V 
*/ 

V 



short be dev [MAXBE -|- l]; /* deviee num of ehans 

short NoBaekends: /* the num of baekends 

short next ehan = 0: /* the next avail ehan 



*/ 

V 



struet sd { 

i n t 1 en ; 
ehar p t r ; 

} j * string deseriptors for; 

j* the network deviee name 
netnam = { 5 , " NET: " } . 



V 

V 



/ * the ma ilbox n ame 
netmbx = { 8, "G_NETMBX" }; 



struet 



ms g hd r head; 
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/’ system running flag 



ma in ( ) 

{ 

int StopSys; 






# i f de f EnExF 1 ag 

printf ("Enter G_PCLB\n"); 

|:end i f 

I* init i n t r a - c ompu t e r c onrnun i c a t i on *j 

i n i t s r ( G PCLB ) ; 

I * set up to use DECNET * / 

n e t i n i t ( ) ; 

StopSys = FALSE; 
wh ile ( IStopSvs ) 

{ 

/ * get a me s s a g e f r om the net wo r k * / 

get _me s s a g e ( <Sans g [ 0 ] , A:h e a d ) ; 

/* send the me s s a g e * / 

set_header() ; 

if( head. type = Stop ) 

{ /* exi t f rom MDBS * / 

StopSys = TRUE; 



head. receiver = RECP ; 
send (ms g, the ad); 

head. receiver = EM; 
send(msg. &head): 

head. receiver = CC ; 
s e n d ( ms g . &h e a d ) ; 

h e ad . r e c e i V e r = P PCLB: 
send(msg. &:head): 

} j * end if part */ 
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else if( head. TV pe == SetBEno ) 

j " set n umb er of backends. "/ 

I* and this backend number. */ 

GPCL. itself, does NOT care */ 
head. receiver = RECP ; 
send(msg. &head); 

h e ad . r e c e i V e r = IM: 
s e n d ( ms g , &:h e a d ) ; 

head. receiver = CC ; 
send (ms g, &:head); 

head. receiver = P PCLB; 
send(msg. &head); 



} 

else if( head. type = 

NewDB II /* create new database 

he ad . t ype = 

T emp late || /* create newt emp late ’ / 

head . type = 

S e 1 e c tDa t abas e ) 

/*assign database to user */ 

{ 

Z’' send to ALL tasks */ 

head. receiver = RECP; 
send(msg, &:head); 

head. receiver = DM : 
send(msg. &head): 
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= i f d e f T i me Flag 



#end i f 



f i f d e f 
pr 

#end i f 



} 



else if ((head, type >= MIN_RP_\ISG'nTE) 
k&z (head, type <= MAX_RP_MSG'nTE) ) 

{ 

head. receiver = RECP ; 
s end (ms g . &he ad ) : 

} 

else if ((head. type >= MIN_CC_MSGTYPE) 
(head.tvpe <= MAX_CC_MSGTYPE) ) 

{ . 

head. receiver = CC ; 
s e n d ( ms g , e a d ) ; 

} ■ 

else if ((head. type >= ML\_IXvI_MSGTYPE) 
M: (head, type <= MAX_DM_MSG'nTE) ) 

{ 

h e ad . r e c e i V e r = IM: 
s end (ms g , &he ad ) : 

} 

else if (head. type = GeTimes) 

{ 

head. receiver = RECP ; 
send(msg,<§ihead) ; 
h e ad . r e c e i V e r = CC ; 
s e n d ( ms g , <fch e a d ) ; 
h e ad . r e c e i V e r = EM; 
s end (ms g , &h e ad ) ; 

} /* end if ( GeTimes ) */ 

else 

/* ( != FINISHED && := GETIMES ) */ 

send (ms g, &head) ; 

} / * end wh i 1 e * / 



EnExF 1 a g 

ntf ("Exi t G_PCLB\n" ) ; 
e X i t ( ) ; 

/ * end ma in * / 
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/’ routine to get the next message from the network * / 

g e t _me s s a g e ( mp t r . h p t r ) 

char *mp t r ; 
struct ms g hdr *hptr: 

{ 

i n t s t a *■ , 

ms glen, 
f un c . 

j . ,k ; 

short iosb[4] ; 
char rcvbuf [MSGLEN + l]. 
i n t b u f [ 2 ] = " \ 0 " , 

tmp s t r [ 5 ] ; 

short ms g r e c ; 



fifdef EnExFlag 

p r i n t f ( " En ter get _me ssage\n") ; 

T= e nd i f 

/* Check mailbox for message notices */ 
read _mb x ( mb x b u f ) : 



/"* Read the me s s a g e * / 
read net(rcvbuf. mb x b u f ) ; 



/* Get the header information */ 
k=0 : 



/"' get sender */ 
for ( j =0 : j < 3 : 

tmp s t r [ j I = 
t mp s t r [ j ] = ’'O' 

hptr->sender = s 



j ++) 

r c vbu f [ k-H-] : 
t r _t o _num( tmp s t r ) : 



j ' get receiver */ 
for ( j =0 ; j < 3 ; j -H- ) 

tmp str[j] = rcvbufjk -I— I- ] ; 
tmp str[j] = ’\0’-; 

hptr->receiver = str to num(tmpstr); 
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/” get the type ’/ 
for (j=0: j < 3: j++) 

tmp str[j] = rcvbuf.[ k-H-] : 
tmp str[j] = '.O'; 

hptr->type = str to num( tmp s t r ) ; 

fifdef pr_flag 

m prnt(rcvbuf. hptr) : 

4^end i f 

I * copy the me s s a g e * / 

j=0; 

while ( (k < MSGLEN) (rcvbufjk] != ECMs g ) ) 

mp t r [ j -H- ] = rcvbufjk -H- ] ; 

nip tr[j] rcvbufjk]: /* get ECMs g * / 

if (k >= MSGLEN) 

p r i n t f ■("*** ^ * Value of MSGLEN ’’ ) ; 
printf(" should be increased *****\^n"); 

T^ifdef EnExFlag 

p r i n t f ( " Ex it get me s s a g e \ n " ) ; 

#end i f 

} ! end get _me s s a g e * j 
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/ > 
/ 



Ron tine to check the ma i 1 b ox for me ssage notices 



/ 



read mb x ( b u f ) 

char "^bnf: 

{ 

short ms g r e c ; 
short stat; 
short iosb[4] : 

^ifdef EnExFlag 

p r i n t f ( "En t e r read mbx\n"); 

#end i f 

msg_rec = FALSE; 

wh i 1 e ( ! ms g r e c ) 

{ 

#ifdef pr_flag 

p r i n t f ( "Ca 1 1 i ng qio, read mailbox\n"): 

#e nd i f 

stat= sys$qiow(0, mbx chan, 10$ READVBLK. iosb, 

“0,0, buf.~MSGLEN, 0,0, 0,0); 

#ifdefpr_flag 

p r i n t f ( "Re t u rned from qio \n"); 

f e nd i f 

if ((stat := SS$_NORU\L) || (iosb[0] != S S $ _NORVL'^L ) ) 

{ 

p r i n t f ( " * * Ma ilbox read error. stat= %d ( %x ) , " : 

printf ("iosb[0]= %d ( %x ) **\n", stat. stat. 

iosb[0]. iosb[0]): 

exit gracefully (); 

} 

switch (buf[0j) 

{ 

case MSG$_INTMSG: 

{ 

ms g _ r e c = TRUE : 
break ; 

} 
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case CONNECT 

I 

\ 

connect(buf): 
break ; 

} 

case MSG$_CONFIRM: break; 

default; { 

printf("** Network error, ") 
p r i n t f ( "mb x b u f [ 0 ] = %d ( %x ) * * \ n " . 

buf[0], buf[0]) 

exit _g raceful ly() ; 

} 

} I * end swi t ch * / 

} / * end wh i 1 e * / 

# i f de f EnExF 1 ag 

p r i n t f ( " Ex it read mb x \ n " ) ; 

#end i f 

} / * end read _mb x * / 
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/ *■ Routine to read a message from a backend ” / 

read_net (rcvbuf. mbxbuf) 

char *rcvbuf, *mbxbuf; 

{ 

short *un i t , 

BEnum, 
f unc , 
s t a t . 
i o s b [ 4 ] ; 

fifdef EnExFlag 

p r i n t f ( " En terreadnet\n"); 

fendi f 

un i t= mbxbu f ; 

for (BEnum = 0 : be_dev [BEnum] ! = un i t [ 1 ] ; BEnum-H-) 

{ 

if (BEnum >= (next chan - 1) ) 

{ 

printf("*** Cannot locate unit number to "); 
printf("read net with. 

printf("*** Searched through %d backends,") 
printf(" next_chan= %d ***\n", BEnum, next_chan); 
exit _g raceful ly() ; 

} 

} 

#ifdef pr flag 

p r i n t f ( " Ca 1 1 i ng qio read from backend %d\n", BEnum) 

^end i f 

func = IO$_READVBLK; 

stat= sys$qi ow ( 0 , be c h an [ BEnum] , func. iosb. 0,0, 

rcvbuf, MSGLEN, 0,0, 0,0); 

#ifdef pr flag 

p r i n t f ( " Re turned fr om q i o \ n " ) ; 

* e nd i f 
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if ((stat := SS$_.\0RMAL) li (iosb[0] != SS$_NORMAL)) 

{ 

printf("'^* Read error be chan %d . s t a t = %d ( %x ) . " ) : 

printf("iosb[0] = %d{%x) . n " . BEnum. stat, 

stat, iosb[0], iosb[0]): 

exit gracefullv(); 

} 

#ifdef EnExFlag 

p r i n t f ( " Ex it read n e t \ n ” ) ; 

fend i f 

} /* end read net */ 
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/" Initialize Decnet to receive connection requests ' j 



n e t _ i n i t ( ) 

{ 

i n t s t a t , i : 
short iosb[4] ; 



#de f i ne 
char 



NFB$C_DECLNAME 0x15 

n f b [ 5 ] = { NFB$C_DECLNAME , 0 , 0 , 0 , 0 } ; 



struct sd { 



i n t 1 e n ; 
char *ptr; 

} 

objnam = { 5, "GPCLB" }, 
nfb_d ={5,nfb }; 



char 



tmp s t r 



#ifdef EnExFlag 

p r i n t f ( " En ter net init\n"); 

fend i f 

/■* create a ma i 1 b o x * j 

s t a t =s y s $ c r embx ( 0 , &mbx chan, MSGLEN, MSGMAX, 0, 0. 



if (stat != SS$_NORM\L) 

{ 

printf{"*’^ Error creating ma i 1 b o x , " ) ; 

p r i n t f ( " s t a t = %d ( %x ) **\n", stat, stat); 

exit graceful lv(); 

} 

/* assign channel to the net */ 

stat= s y s $ a s s i gn ( &:n e t nam, <knet_chan. 0, &:netmbx); 
if (stat != SS$_NORMAL) 

{ 

printf("** Error in assign for netchan, "); 
printf("stat =%d ( %x ) **\n", stat. stat); 

exit graceful lv(); 

} 



<Szne tmbx ) ; 
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/' declare a net wo r k n ame ‘ / 

stat= sys$qiow(0. net_chan. I 0$ _ACPCONTROL . iosb, 

0.0. (Sen f b d . <Seo b j n am , 0 , 0 . 0 , 0 ) ; 

if ((stat != SS$_NORMAL) |1 (iosb[0] != S S $ _NOR\l\L ) ) 

{ 

printf("*’^ Error declaring network name **\n"); 
exit gracefully(): 

} 



#ifdef EnExFlag 

printf("Exil net init\n"); 

# e nd i f 

} 
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/" routine to accept a network connection 
c onn e c t ( bu f ) 



request 






char * bu f ; 

{ 

short 

offset, 
s t a t , 
i o s b [ 4 ] ; 



char 


nodespec [ 128] ; 






struct 


s d { 












i n t 


1 e n ; 










char 

\ 


’ p t r ; 










/ 

neb 


= { 


0 . 


nodespec }; 




1 ong 


dv i un 


it[l] 


1 






short 


d V i u n 


it 1 en [ 1 I 






/* structure to 


ge t 


un i t 


n umb ers for channels to 


the net 


struct 


{ 

short 


1 e n ; 




/* buffer length * / 






short 


code 




/ * it em code * / 






1 ong 


un i 


t ; 


/* addr to return unit 


to */ 




short 


*un i 


t 1 e n 


: /"* length of un it * / 






1 ong 


nu 1 ; 




end of descriptor * / 


1 




; 

d V i = 


{ 4. 


DVI $ 


UNIT, dviunit, dviunit 1 


1 e n , 0 } 


f i fdef 


EnExF 1 ag 












p r i n t f ( " 


En ter 


connect \n") ; 




f e nd i f 












/* see if the 


re are any channels available */ 





if (next chan > MAXBE ) 

{ 

printf("** Too many connection requests "); 
p r i n t f ( " a t t emp t e d . next chan= %d *^\n", next_chan); 
exit graceful ly(): 

} 
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/ ’ Ex tract n e two rk connect block fr om ma ilbox buffer 



^ / 
/ 



offset = buf[4] + 5; / '’ point to neb length in bu f */ 

ncb.len = buf[offset]; j * put length into our neb */ 

offset +- 1- : /*pointpastncblength ’/ 

for ( i =0 ; i < ncb.len; i++) /* get the neb */ 

nodespeeji] = buf [i + offset]: 
nod e s pe c [ i I = ’ \ 0 ' ; 

fifdef pr_flag 

printf("** nodespec= %s **\n". node spec); 
printf("*'*' next chan= %d **\n", next chan); 

#end i f 

/* Assign the next channel to the net */ 

stat= s y s $ as s i gn (itn e t n am, &be chan [next chan], 0, 

&ne tmbx ) ; 

if ( stat != SS$_NORMAL) 

{ 

printf("** Assign error be chan %d , " ) ; 

printf("stat= %d (%x) **\n",next chan, stat, stat); 
exit graceful lv(); 

} 

/* accept the connection */ 

stat= sys$qiow(0. b e _c h an [ ne x t _c h an ] . 10$ ACCESS. 

i o s b . 0.0,0, &n cb. 0,0, 0,0); 

if ((stat != SS$_NORM.\L) j| (iosbfOj ! = S S $ _NORMAL ) ) 

{ 

printf("** Accept error be chan %d , stat= %d(%x),"); 
printfj" iosb[0]= %d(%x) **'n". next chan, stat, 

stat. iosb[0], iosb[0j); 

exit graceful ly(); 

} 
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/' Get unit numbers for the channels '/ 
stat= sys$getdvi(l, be_chaninext_chan]. 

0 . &(! vi. iosb. 0.0.0): 

if (stat !=SSS _NORM.A.L ) 

{ 

printf("** Error getting channel number for BE "); 
p r i n t f ( "%d . s t a t = %d {%x ) * * \ n " , 

next chan, stat, stat); 

exit _g raceful ly() ; 

} 

sy s $wa i t f r ( 1 ) ; 

if (iosb[0] != SS$_NORMAL) 

{ 

printf("** Error getting channel number for BE "); 
p r i n t f ( " %d , i o s b [ 0 ] = %d ( %x ) **\n", next chan, 

iosb[0], iosb[0]); 

exit_graceful ly() ; 

} " 

be de V [ nex t _c han ) = *dviunit; 

/ increment the available channel pointer */ 
n e X t c h an-H- ; 

# i f de f EnExF 1 a g 

p r i n t f ( " Ex it connect\n"); 

# e nd i f 

} I * end connect * / 
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I' Routine to disconect all of the network links */ 

disconnect() 

{ 

i n t s t a t . i : 

#ifdef EnExFlag 

p r i n t f ( " En ter Disconnect 'n"); 

|:e nd i f 

for (i=l; i < next_chan; i+-f) 

{ 

# i f de f pr_f 1 ag 

p r i n t f ( "Di s c onne c t i ng backend %d\n", i); 

f e nd i f 

stat= sy s $da s s gn ( be _c han [ i ] ) ; 
if ( s tat != SS$_NORmL) 

p r i n t f ( " * Dassign Error for backend %d . "); 

printf ("stat= %d ( %x ) **\n", i, stat, stat); 

} 

# i f de f EnExF I ag 

p r i n t f ( ” Ex it Disconnect\n"); 

fend i f 

} 

/ * S ET HEADER assigns values to the ms gheader * / 

set header () 

head. sender = G_PCLB : 

/* set the receiver */ 

head, receiver = EM ; /* thedefault * / 

} / end set header */ 



j ^ Close all network connections before aborting **j 

exit graceful ly() 

{ 

sleep (DELAY) ; 
disconnect(); 
ex i t ( ) ; 

} 
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APPENDIX D - THE MBDS BACKEND PUT-NET SOURCE CODE 



j ^ ^ 

/* VAX/VMS P_PCLB * 

I * * 



/ 

/ 

/ 

/ 

/ 



# i n c 1 ud e 


< s t d i 0 . h> 


/* 


Standard I/O definition 


V 


i n c 1 ud e 


<s sde f . h> 


/* 


VMS return status codes 


V 


§\nc 1 ud e 


< i od e f . h> 


/* 


VMS I/O return codes 


V 


# i n c 1 ud e 


<ms gde f . h> 


/* 


DECNET ms g definitions 


V 


# i n c 1 ud e 


" e oirmd a t a . d e f 


II 


/* MBDS common defs 


V 


# i nc 1 ude 


"ms g . de f " 




/* MBDS ms g- type defs 


V 


fine 1 ud e 


"flags .def" 




/ * \;IBDS c omp i 1 e flags 


V 


fine 1 ud e 


" b e n o . d e 1 " 




/ backend num declares 


V 


#d e f i ne 


MAXBE 16 




/* max num of backends 


V 


e h a r 


netbuf [MSGLEN] ; 




/ "^ network buffer 


V 


e h a r 


mbxbuf [MSGLEN] ; 




/* mailbox buffer 


V 


e h a r 


ms g [MSGLEN] ; 




/* MBDS -ms g buffer 


V 


short 


net e h an : 




/* channel to DECNET 


*/ 


short 


mbx chan; 




/* channel to mailbox 


V 


short 


be chan [MAXBE -f 


1 


] ; /* chan’s to backends 


V 






/* 


backend 0 is controller 


*/ 


short 


NoBac k ends ; 




/ * the n um of backends 


*/ 


short 


next chan = 0 ; 




/ * the next avail chan 


*/ 


s t r ue t s 


d { 










i n t 1 e n ; 










char *ptr; 










} / * string 


d e 


scriptors for: */ 






/* the network 


device n ame * / 






n e t n am == { 5 , 


II 


NET : " } , 






/ * the ma i 1 b o x 


n ame * / 






ne tmbx = { 8 , 


II 


P NETMBX" } ; 




s t r ue t 


ms g hdr head; 
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ma in ( ) 

{ 

i n t i ; 

int StopSys; /* loop flag ’/ 

i nt j . k ; 

char NoBEs [NoBEl ength +1 ] ; 

char BE Numbe r [ NoBEl eng t h +1 ] ; 



^ifdef EnExFlag 
p r i n t f ( " En ter p _p c 1 b \ n " ) ; 
f end \ f 

/ * Initialize intfa-c omp u t e r c ommu nication * / 
i n i t s r ( P PCLB) ; 

/ * set up to use DECNET * / 
control ler_net_init ( ) ; 

I * receive a me s s a g e f r om the controller * / 
receive (&ms g [ 0 ] , &h e ad ) ; 

I * The first message should be of type Set BEn o . * / 

if ( head. type != SetBEno ) 

{ 

printf( "Error in PPCL, 1st message must "); 

printf("be of type SetBEno" ); 

printfj " Type = %d \ n " , h e a d . t y p e ) ; 

m_p r n t ( &ms g [ 0 ] . &h e a d ) ; 

exit graceful ly(); 

} 

/* get number of backends */ 

f o r ( k=0 , j =0 ; ( NoBEs [ j ] = ms g [ k ] ) ! = ’ \ 0 ’ : 

k-l— t- , j -H- ) ; 

NoBackends = str to num( NoBEs ) : 
k H ; 

I* get backend number */ 

f o r ( j =0 ; ( BE N umb e r [ j ] = ms g[k]) != ’\0’: 

k+^-, ) ; 

BACKENT)_NO = str_to num( BE Number ) ; 
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ba c k end_ne t _i n i t ( XoBa c k end s . BACKEXD NO); 

/ ^ ma in portion of progr am ^ / 

StopSys = F AL S E : 
while ( IStopSvs ) 

{ 

/ * r e c V a ms g f r om a BE process * j 
r e c e i V e (&ms g [ 0 ] . &head); 

if ( head. type = Stop ) 

{ 

StopSys = TRUE ; 

/* send the ms g over the network */ 

/* backend 0 is the controller * j 
put_message (&msg(0] . <Sihead. 0) : 

} 

else if ( head. type = Desclds ) 

{ I* send Desclds to other backends */ 
h e ad . r e c e i V e r = EM; 

for ( i = 1 ; i <= NoBackends : i = i -1- 1 ) 

{ 

/* send the Desclds to other backends */ 
i f ( i ! = BACKEND_NO ) 

{ 

put _me s s a g e ( &ms g [ 0 ] , <S^h e a d . i ) : 

} 

}/* end for */ 

}/* end else if */ 
else 

{ 

/* send all other messages to controller */ 

/* backend 0 is the controller / 

pu t _me s s ag e (ms g , <khead, 0); 

} /* end else */ 

} / * end wh i 1 e * j 
i f d e f EnExF 1 ag 

p r i n t f ( " Ex i t p _p c 1 _b \ n " ) : 
e nd i f 



} / * end. ma in * / 
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/’ routine to send a message over the network "/ 

put me s s a g e ( mp tr .hptr .BEn um) 

char '’ mp t r : 
struct ms g hdr '’'hptr; 
int BEnum: 

{ 

int s t a t , 

ms glen, 
f un c , 

j , k ; 

short iosb[4] ; 

char sndbuf [MSGLEN + l], 

intbuf[2] = "\0", j* null message *j 
tmp s t r [ 5 ] ; 



f i f d e f EnExF 1 ag 

p r i n t f ( " En t e r put message\n"): 

e n d i f 

hptr -> sender = P PCLC; 
hptr -> receiver = G_PCLB; 

k=0 : 

j * copy header into me ssage to be sent * j 

1 e n n um to str(hptr->sender, 3. t mp s t r ) ; 
for ( j=0 ; j < 3 ; j-|-+) 

s n d b u f [ k -I— I- ] = t mp s t r [ j ] : 

1 e n n um to str(hptr->receiver. 3. tmp s t r ) : 
for ( j =0 ; 'j < 3; j-H-) 

s ndbu f [ k-H-] = tmp s t r [ j ] ; 

1 e n n um to str(hptr->type, 3, t mp s t r ) ; 
for ( j =0 ; j <3; j-H-) 

s ndbu f [ k-H-] = tmp s t r [ j ] ; 
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/■ cop>' the me s s a g e / 
j=0: 

while ( (k < MSGLEN) 6 :^ 

( ( s ndbu f [ k-r+] = mp t r [ j -H-] ) ! = ECMs g ) ) ; 



if (k >= MSGLEN) 

p r i n t f ( " * ' * * * Value of MSGLEX " ) : 
printf(" should be increased 

ms glen = k : 



/* send the me s s a g e * / 



#ifdef prj^flag 

p r i n t f ( "Ca 1 1 i ng qio write to backend %d\n”, 

BEnum) ; 

m_p rn t ( sndbu f , hp t r ) ; 

T?end i f 

func = I08_WRITE\^LK; 

stat= sys8qi ow ( 0 . be c h an ( BEnum] , func. iosb, 0,0. 

sndbuf. msglen. 0,0, 0,0) 

?=ifdef pr flag 

p r i n t f ( "Re t u r n ed from qio, write \n"); 

^end i f 



if ((stat != SS$_NORMA.L) II ( i osb [ 0] ! = S S $ _NORMA.L ) ) 

{ 

printf("** Wr ite error be chan %d . s t a t = %d " ) ; 
p r i n t f ( " {%x ) . i o sb [ 0 I = %d (%x ) * * \ n " , BEnum, 

stat. stat. iosb[0], iosb[0|) 

exit gracefully(); 

} 



I* let receiver know ms g is there */ 
fifdef pr_flag 

p r i n t f ( "Ca 1 1 i ng qio, i n t e r rup t \n " ) ; 

fend i f 

func = I0$_WRITE\':BLK I 1 0$M_ INTERRUPT; 

stat= s y s $ q i ow ( 0 . be chan[BEnum| , func, iosb. 0.0. 

i n t bu f, 1, 0,0, 0,0) 



91 



^ i f d e f 



p r flag 

p r i n t f ( "Re turned fr om qio. interrupt n"): 

#end i f 

if ((stat !=SS$ _NORMA.L )|l(iosb[0] !=SS$ _NORMAL ) ) 

{ 

printf("** Interrupt error be chan %d , s t a t = %d " ) 
p r i n t f ( " (%x ) , i o s b [ 0 ] = %d (%x ) * * \ n " . BEnum, 

stat, stat, iosb[0]. iosb[0]) 

exi t_g raceful ly() ; 

} 



# i f de f EnExF 1 ag 

printf("Exit put me s s age \n " ) : 

# e h d i f 

} 
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Routine to initialize Decnet to recei\’e connections 



/ • 



control ler_net init() 

{ 

i n t s t a t . i ; 
short iosb[4] ; 



^define NFB$C_DECLNAME 0x15 

char nfb(5] = { NFB$C_DECLNAME , 0 



struct sd { 

i n t 1 en ; 
char ’^ptr; 

} 

objnam = { 5 , "PPCLB" } , 
nfb_d ={5, nfb }; 



char 



tmp s t r [ 5 ] ; 



ftifdef EnExFlag 

printf(" Enter control ler_net_in 

f e nd i f 



/* create a ma i 1 b o x * / 
s t a t =s y s $ c r embx ( 0 . &mbx chan, MSGLEN 

0 

if ( s tat != SS$_NORMA.L) 

{ 

printf("*’^ Error creating mailbox 
printf ("stat= %d ( %x ) **\n", stat 

exit graceful ly(); 

} 

/* assign channel to the net */ 
stat= s y s $ a s s i gn ( <S^n e t n am, &net chan, 
if (stat !=SS$ _NORMAL ) 

{ 

printf("*" Error in assign for ne 
printf("stat =%d ( %x ) ’'*\.n", stat. 

exi t_g raceful ly() ; 

} 



, 0 , 0,0 } ; 

i t \ n " ) ; 

, MSOVL^X. 

, 0 , <kn e tmbx ) ; 

, stat): 

0 , &n e tmbx ) ; 

t c h an . " ) : 

stat) ; 
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/■ declare a net wo r k n ame " / 

stat= sysSqi ow (0. net _c ban. 10$ ACPCONTROL . 

iosb. 0.0. &:nfb d. &objnana. 0.0. 0.0): 
if ((stat := SS$_.\ORMAL) I 1 ( iosb[0] ! = S S $ _NORM.\L ) ) 
{ 

printf("** Error declaring network name **,n") 
exit gracefully(); 

} 

/* check mailbox for connection requests *j 
read mb x ( mb x b u f ) ; 

/* accept the connection */ 
c o n n e c t ( mb x b u f ) ; 

# i f de f EnExF 1 ag 

printf("Exit control ler_net init^n"); 

#end i f 

} 
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/" Routine to initialize Decnet links to backends ’/ 
b ac k e nd_n e t _ i n i t ( NoBEs . BEnum) 
i n t NoBEs ; 

{ 

i n t s t a t . i : 
short iosb[4] : 

char nodespec[l28] , t mp s t r [ 5 ] ; 

struct sd{ 

i n t 1 e n : 
char *ptr: 

} 

n e t n am = { 5 , " NET : " } , 

neb = { 0. nodespec }; 

£ i f d e f EnExF 1 a g 

printf(" Enter backend _net_init\n") : 

#end i f 



for(i=l; i <= NoBEs; i++) 

{ 

if ( i ! = BEnum ) 

{ 

/* assign a channel to the net 

stat= sys$assign( <k:ne t nam, &b e_chan[i], 0, 0); 

if (stat != SS$_NORMA.L) 

{ 

printf("** Error in assign be_chan %d , "); 

printf ( "stat= %d ( %x ) **\n". 1. stat, stat); 

exit _g raceful ly() ; 

} 

} /"*■ end if i != BEnum */ 

} ! * end for */ 
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/' Establish logocal link ’/ 
for ( i =1 : i <= XoBEs : i -H- ) 

{• 

if ( i ! = BEnum ) 

{ 

I* build network connect block */ 
strcpy(nodespec, "CSM\^" ) ; 
n um t o s t r ( i , tmp s t r ) ; 
strcat (nodespec, tmpstr); 
strcat (nodespec, " ; : \ " 0=GPCLB\ " " ) ; 

fifdef pr_flag 

printf ("backend %d nodespec. "); 
p r i n t f ( " \ "%s \ " \ n " , i . nodespec); 

# e nd i f 

ncb.len= s t r 1 en ( node spe c ) : 

/* Request the connection */ 

stat= sysSqi ow( 0 . be c han [ i ] , 10$ ACCESS . 

i o s b , 0.0,0, &n cb. 0,0, 0.0); 

if ((stat != SS$_NORMAL) I I ( iosb [0] ! = S S S _NORMAL ) ) 

{ 

p r i n t f ( " '*' Access error be_chan %d . "); 

print f("stat= %d ( %x ) , i o s b [ 0 ) = %d ( %x ) * \ n " , 

i. stat. stat. iosb(0], iosb[0]); 
exit graceful lv(): 

} 

} /* end if i != BEnum */ 

} /* end fori*/ 

#ifdef EnExFlag 

printf ("Exit backend net init'n"); 

e nd i f 

} 
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j Routine to check the ma i 1 b o x for me ssage notices ' j 
read mb x ( b u f ) 



char * bu f : 

{ 

short connect rec; 
short stat; 
short iosb[4] ; 

f i f de f EnExF 1 ag 

printf( "Enter re ad_mbx \ n " ) : 

#end i f 



connect rec = FALSE; 



wh i 


1 e ( ! c onn e c t rec ) 




{ 








f i f d e f 


p r flag 








p r i n t f ( "Ca 1 1 i ng 


qio, read 


ma i 1 box\n" ) ; 


iend i f 








s 


tat= sysSqi ow ( 0 , 


mb X chan, 


10$ READVBLK, 






i o s b , 0,0, 


buf, MSGLEN, 


# i f d e f 


pr flag 







p r i n t f ( "Re t u r n e d from qio \n"); 

i^end i f 

if ((stat != SS$_NORMA.L) I I ( iosb [0] ! = S S $ _NORMA.L ) ) 

{ 

printf("** Ma ilbox read error, stat= %d ( %x ) , " ) ; 
printf(" iosb[0]= %d ( %x ) **\n". stat. stat. 

i o s b[0] , i o s b [ 0 ] ) ; 

exit graceful ly(); 

} 

sw i t c h ( bu f [ 0 ] ) 

{ 

case MSG$_CONNECT; 

{ 

connect rec = TRUE ; 
break : 

} 
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case MSG$_COXFIRM: 

case MSG$_L\TMSG ; break: 

default: { 

printf("** Network error, "); 
p r i n t f ( "mbxbu f [ 0 ] = %d (%x) **\n", 

buf(0], buf[0]) 

exit _g raceful ly() ; 

} 

} j * end sw i t c h * / 

} ! * end wh i 1 e * / 

# i f de f EnExF lag 

p r i n t f ( " Ex it read mb x \ n " ) : 

l^end i f 

} /* end read_mbx */ 
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/"* routine to accept a network connection request "/ 
connect (buf) 



char *buf; 

{ 

short i , 

offset , 
s t a t , 
i o s b [ 4 ] ; 



char node spe c [ 1 2 8 j ; 

struct sd { 

i n t 1 e n ; 

char *ptr: 

} 

neb = { 0. nodespec }; 

ft i f d e f EnExF 1 ag 

printf(" Enter connect\n"); 

ftend i f 



/ Extract network connect 

offset = buf[4] + 5: /* 

ncb.len = buf[offset]; /* 

of f s e 1 4 — h I / * 

for ( i =0 ; i < ncb.len; i-H-) 
nodespec[i| == buf [i + 
nodespec[i]= ’\0’; 



block f r om ma ilbox buf */ 

point to neb length */ 

put the len in our neb */ 
point past neb length */ 
I * get the neb */ 

offset] ; 



ftifdef pr flag 

print f("** 
p r i n t f ( " * " 

ttend i f 



nodespec= %s **\n". nodespec) ; 
next chan= %d **\n", next_chan); 
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/“ Assign controller channel to the net ’/ 

stat= sys$assign( i:n e t n am . <§cb e c h a n [ 0 ] . 0 . &:n e t mb x ) 

if (stat := SS$_NORM\L) 

{ 

printf("*'^ Assign error be chan %d , " ) ; 

printf("stat= %d (%x) **\n", next_chan, 

stat, stat) 

exitgracefully(): 

} 

I"’ accept the connection */ 

stat= sys$qiow(0, be_chan[0] , IO$_ACCESS. 

iosb, 0,0,0, <kncb. 0,0. 0,0) 
if ((stat := SS$_NORMAL) I 1 ( i osb [ 0] ! = SS$_NORMAL) ) 

{ 

printf("** Accept error be_chan %d , " ) ; 

printf("stat= %d ( %x ) . i o s b [ 0 ] = %d ( %x ) * * \ n " . 

next chan, stat. stat, iosb[0]. iosb[0j) 
exi t graceful ly( ) ; 

} 

fr i f de f EnExF 1 ag 

p r i n t f ( " Ex it connect \n"); 

^end i f 

} / * end connect * / 



100 



routine to disconnect all network links ’/ 



disconnect (.) 

{ 

i n t s t a t . i ; 

# i f d e f EnExF 1 ag 

printf(" Enter D i s c onn e c t \ n " ) ; 

#end i f 

for (i=l: i <= NoBackends; i-l— k) 

{ 

#ifdef pr_flag 

p r i n t f ( "D i s c onn e c t i ng backend %d\n'', i); 

y end i f 

stat= sys$dassgn(be chan[i]); 
if ( s t a t ! = S S $ _NORmL ) 
printf("** Deassign Error for backend %d . "); 

printf (”stat= %d ( %x ) ’*^*'n",i,stat. stat); 

} 

fifdef EnExFlag 

printf ("Exit D i s c onn e c t \ n " ) ; 

^send i f 

} 



/* Routine to close network connections then abort */ 
exi t_g raceful lv( ) 

{ 

s 1 e e p ( DELAY) ; 
disc onne c t ( ) : 
ex i t ( ) : 

} 
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